Larger businesses spend more on their websites than smaller ones, which means their mistakes are correspondingly more expensive. But the patterns of failure for NZ businesses at enterprise scale are not primarily about insufficient resources. They are about organisational dynamics that money does not solve and that most agencies are reluctant to name clearly because naming them requires telling a client that their internal processes are the problem.
The businesses that get strong outcomes from significant website investments have almost always done something about these dynamics before the project starts. The ones that do not tend to produce expensive, well-made assets that perform below their potential from day one.
The RFP that selects for compliance, not capability
The Request for Proposal process is the standard mechanism for selecting agencies in organisations large enough to have procurement functions. It is also one of the more reliable ways to avoid selecting the best agency for the job.
An RFP works by asking multiple suppliers to respond to a brief. The brief is typically written by someone in marketing or IT who is trying to specify the project requirements in advance. The responses are evaluated against a set of criteria: price, process, relevant experience, credentials. The agency with the most coherent response and acceptable price wins.
The problem is that the capability that matters most in a website project is strategic and creative judgment, and this capability is very difficult to assess through a written document. The RFP process selects for agencies that are good at responding to RFPs, which is a different skill. The agency that submits a methodologically thorough, professionally formatted proposal with case studies formatted to the brief's specifications is not necessarily the agency that will make the best design decisions, ask the right difficult questions or produce the strongest commercial outcome.
For NZ businesses at larger scale, the alternative is not to abandon due diligence. It is to add a qualitative stage to the selection process: a working session with shortlisted agencies, a review of unreferenced work alongside referenced work, direct conversations with people who would manage the account rather than business development staff. These steps take more time than reading proposals. They are also more predictive of the actual working relationship.
Briefs written to the organisational chart
Enterprise website briefs tend to be assembled by committee, with input from marketing, IT, sales, product and often legal and compliance. Each function adds its requirements. The resulting brief specifies what everyone needs the website to do, which is not the same as what the website needs to do for the visitor.
The output of this process is typically a homepage brief that attempts to accommodate all business functions simultaneously. The homepage needs to serve enterprise customers and SMBs. It needs to reflect the full product range without prioritising. It needs to incorporate the new brand direction from marketing, the performance requirements from IT, the lead capture requirements from sales, and the compliance disclaimers from legal. The result is a homepage that is technically compliant with all internal requirements and structured around the organisation's needs rather than the visitor's.
A brief built around the visitor starts from a different question: who arrives on this page, what are they trying to determine, and what is the one thing we most need them to do. For most enterprise B2B businesses with a sales-led model, the visitor is a decision-maker early in a buying process who needs to understand quickly whether this is a credible solution to a problem they are trying to solve. Everything else is secondary to answering that question clearly. The homepage should be designed around that visitor, not around the internal political requirements of the business.
The IT authority problem
In larger NZ organisations, IT typically has authority over hosting, security requirements, technology selection and sometimes design system governance. This is appropriate for enterprise IT infrastructure. It produces specific problems when applied to website platforms and development stack decisions.
IT security requirements are often derived from enterprise software standards that were developed for internal systems: databases, ERP platforms, authentication systems. Applied to public-facing websites, these requirements can prohibit the use of platforms like Webflow or Shopify, restrict deployment to on-premise hosting environments that are significantly slower than modern CDN-delivered infrastructure, or require security reviews that take months and block launches.
The effect is that marketing teams end up with websites running on legacy platforms that IT approved years ago, hosted on internal servers that were not designed for high-traffic web delivery, managed through content management systems that require developer involvement for any change because they were selected for compliance with IT standards rather than for the marketing team's actual needs.
This is not a problem without a solution, but the solution requires a genuine conversation between IT and marketing about what the website is actually trying to do and what the appropriate security posture is for a public-facing marketing asset versus an internal financial system. Most organisations have never had this conversation explicitly. They have just let IT authority extend to decisions where it produces genuinely bad outcomes.
The two-year rebuild cycle
Many larger NZ businesses operate on an implicit or explicit cycle where the website gets a significant rebuild every two to three years. The rebuild is often triggered not by performance data but by the website looking dated relative to competitors, or by a change in agency, or by a new brand refresh, or simply by the sense that it has been long enough since the last one.
This pattern produces a particular kind of waste. A website that has been live for two years has accumulated SEO equity, user familiarity, analytics data and performance history. A rebuild that discards this history in favour of a fresh start sacrifices real commercial value for the aesthetic value of a new design.
The alternative is a model where the website is treated as a product rather than a project: continuously improved based on performance data, updated incrementally rather than rebuilt periodically, with significant design changes tested before full rollout. This requires a different agency relationship than the project-based model, and it requires internal capacity to manage ongoing work rather than briefing a new build every few years. It also produces meaningfully better commercial outcomes over time because the site gets smarter as it accumulates data rather than resetting every two years.
The content ownership gap
Enterprise websites typically have a lot of content: service pages, industry pages, case studies, blog archives, resource libraries. This content is created by multiple teams over time and managed through whatever CMS was selected when the current site was built. Nobody is usually responsible for the overall content strategy, which means the site accumulates content without a systematic approach to maintaining or retiring it.
The effect on SEO is similar to what happens in smaller businesses: a large pool of thin, outdated or duplicated content that dilutes the domain's overall content quality signal. At enterprise scale this problem is often larger in absolute terms and harder to address because the content spans multiple business functions, nobody has clear authority to retire content from another function's section, and the CMS makes bulk content changes difficult.
Addressing this requires assigning content ownership at the strategic level, not just the operational level. Someone, or some function, needs authority over the website's overall content direction: what topics the site should cover, what content should be maintained versus retired, how the content strategy connects to the commercial priorities of the business. Without this authority, individual teams continue adding content that serves their function and the aggregate quality of the site continues to decline.
The performance measurement gap
The enterprise organisations that consistently improve their website performance over time have one thing in common: someone in the business cares about specific performance metrics and has authority to act on them. The metric might be qualified lead volume, it might be conversion rate from organic traffic, it might be the cost per acquisition from the website channel. The specific metric matters less than the fact that it exists, is tracked, and drives decisions.
Most larger NZ businesses have Google Analytics installed. Very few of them have translated the data in Analytics into specific performance targets that the website is held accountable for. The website exists. It generates some traffic. It produces some leads. Whether it is performing well or poorly relative to what it should be capable of is a question that most organisations cannot answer because they have never established what the target is.
The solution is not complex: define the metrics that matter, establish a baseline, set a target, review performance against the target quarterly, and make changes when the target is not being met. This is normal business practice for most commercial functions. It is surprisingly uncommon for the website, which for most B2B businesses is generating the majority of the top-of-funnel activity that eventually becomes revenue.
The businesses that treat their website as a commercial asset managed to specific outcomes get better outcomes from it. That is not a surprising observation. What is surprising is how many NZ businesses at significant scale are still treating their website as a cost centre to be managed rather than an asset to be optimised.
