AWS recorded US$128.7 billion in sales in 2025. Using an exchange rate of NZ$1.67 to the US dollar, that's ~NZ$215 billion. New Zealand’s entire government collected NZ$121.1 billion in tax revenue during the year to June 2025...
The comparison is imperfect for sure: AWS has vast computing resources, global access to technical talent and enough investment capacity to run parallel AI experiments at once, every day. It also had McKinsey working alongside dedicated AWS teams during the transformation covered in a recent McKinsey article outlining the lessons learnt from its transformation.
So with all that being said and the completely uneven (and somewhat odd) playing field, what could an SME New Zealand company possibly learn from that?
The value sits in the decisions underneath the scale AWS benefits from.
AWS chose where to focus, aligned on which information and context could be trusted by people and AI, redesigned how work moved through the org, and found ways to make new behaviour stick (no small feat in a business of that scale!). Those are familiar problems in smaller businesses, although the solutions look very different.
And through Allexive and The AI Corner, I regularly see businesses (big and small) struggle to turn individual AI experiments into a better way of operating.
To make the translation concrete, imagine two hypothetical businesses.
One is a 30-person professional-services consultancy where revenue depends on expert knowledge and the time of a few senior partners.
The other is a 120-person building-products distributor where pricing, product information and delivery decisions move across several departments.
The consultancy’s scarce resource is senior judgement, whereas the distributor’s is coordinated attention at volume. We'll run both examples through the lessons AWS presents us with.
Lesson 1 from AWS: Pick the domain and define the end state
AWS, and what changes locally
AWS chose one domain: go-to-market. That still covered sales, marketing, partners and global services across almost 40,000 field employees, but it ringfenced the transformation to a 'department' (ha).
The decision followed the fact there is years of accumulated complexity, knowledge and opportunity in this department. AWS had more than 200 first-party tools, and its opportunity-to-cash process connected into more than 40 systems. By early 2025, teams across the company were building agents that risked creating another layer of fragmentation that the business doesn't need.
For either of our New Zealand businesses, “go-to-market” would be far too broad a definition.
At the consultancy, almost everyone contributes to winning or delivering work.
At the distributor, the domain could include half the company.
What it means for the two NZ businesses and how I'd apply the lesson
Don't pick a whole department or function to necessarily start with. Some might start with a team, that's also okay. But my view is a local business needs a boundary much closer to a customer outcome than a department.
The consultancy chooses the journey from qualified opportunity to client-ready proposal.
Once it decides to pursue an opportunity, the team should be able to find relevant customer experience / case studies, current staff credentials and approved commercial assumptions.
AI prepares a working draft, while a partner remains responsible for the approach, price and promises made to the client = the human-in-the-loop sign off and accountability for, firstly, the file proposal delivered, and, secondly, the customer outcome.
The distributor chooses non-standard quote-to-order.
A salesperson should be able to see the customer’s history, applicable pricing, current product information and delivery options together.
Finance and operations become involved when an exception requires their authority.
Lesson 2 from AWS: Fix the data before scaling the agents
AWS, and what changes locally
AWS had information spread across systems with different definitions, multiple uses and owners (there were more than 75 definitions for field roles alone). Employees were forced to reconcile these differences manually because it's something an agent could not do reliably.
AWS consolidated hundreds of datasets into 20 foundational data sources and standardised core definitions across the business for ease of understanding and use. This work had begun years earlier, which for a big company is just another initiative for a team.
For a smaller company, they cannot wait for the same level of planning or preparation, nor should the business connect an AI assistant or agent to every file and hope that the model works out which one is the current version of the truth. The flip side is smaller companies aren't dealing with the same volume of data sources to work through and often less complex data by virtue of scale.
The local version is to settle ownership of the information required for the chosen workflow while the first solution is being built, rather than reorganising every data source and cleaning up pipelines for a whole function as the first step of rectifying the situation.
What it means for the two NZ businesses and how I'd apply the lesson
Most of the consultancy’s useful information is unstructured. It sits in old proposals, project descriptions, staff biographies and the memories of senior people.
The firm could create a small approved library for proposals and contributing files to proposals as context steering documents.
A practice lead owns the project examples, operations maintains current biographies and a partner owns the scope and commercial terms and assumptions. AI may find a past project, but a person decides upfront which files the AI should be reading from in the first place, and ensuring all information is relevant and safe to claim.
The distributor has a more structured problem. Prices appear in three different places the finance system, a sales spreadsheet and customer PDFs. Plus contract terms live in email, and product information is spread across supplier files and an outdated specification folder in different formats (Word docs, spreadsheets, image files, and PDFs).
For quoting, it chooses one approved source for customer records, pricing, product information and delivery commitments.
Each source needs to have an owner to maintain.
The company also settles upfront recurring arguments such as which price applies when a promotion overlaps with a contract, so that those rules are all codified.
Neither business needs a company-wide data programme.
The consultancy makes its knowledge easier to find without confusing retrieval with judgement.
The distributor reduces errors and its dependence on the employee who has been reconciling conflicting systems from memory, creating workarounds along the way. This is more about process and standards alignment, guiding towards the right files.
Lesson 3 from AWS: Redesign the work, then put AI inside it
AWS, and what changes locally
AWS studied roughly 35 roles across almost 40,000 field employees. It examined where people spent time preparing, gathering information and completing admin. Employees were also developing agents for their own individual and local problems which AWS shared that not every idea was useful through conducting its formal analysis.
AWS reports that agents reduced customer-strategy preparation by approx. seven hours per engagement, all through shifting from a focus on making isolated tasks faster to instead redesigning connected work.
Neither New Zealand business in our example needs a study of every role. People in the consultancy perform blended jobs, while reviewing how the workers in our distributor’s departments separately could misunderstand, or even just miss, the delays and coordination between them.
The better approach is to follow one piece of work from beginning to end and record where it stops thanks to humans, and begin to unpack what work redesign means in that context.
What it means for the two NZ businesses and how I'd apply the lesson
At the consultancy, a partner has a promising client conversation and asks a manager to prepare a proposal.
Old process: The manager searches old folders, asks colleagues for examples and waits for current colleague biographies and rates to quote. AI drafts the document quickly, but the partner rewrites it because the scope does not reflect the original conversation.
The redesigned process: begins with the partner recording the client’s problem, stated objectives and any commitments they've already made. The system then retrieves approved business examples and experience to call out, and prepares a working scope and first pass at commercials. The manager checks the evidence of the business's experience, and the partner focuses on the approach and commercial judgement. Less involvement in producing the output (ideally that's triggered autonomously) and full focus on reviewing AI's first pass.
At thedistributor, a customer requests a non-standard quote.
**Old process:**the salesperson drafts an acknowledgement to the customer, then waits for finance to confirm pricing, ops to check delivery and a product specialist to verify the specification. Each answer takes minutes to produce but hours to arrive because the friction is due to humans being focused on multiple tasks and jobs, all at once. Coordination is the big task. Three days later, the quote goes out.
The redesigned process: gathers customer history, checks approved pricing and adds current product information. Operations receives a structured delivery question to answer about the quote, and routine requests move to review, while complex exceptions reach the person authorised to decide them based on preset rules by the business.
The consultancy measures the time from opportunity-pursuit-decision to client-ready proposal and the amount of partner rework. The distributor measures the time from request to approved quote and the number returned for correction.
Both are measuring the work the customer experiences (the output).
Lesson 4 from AWS: Build adoption and measurement into the work
AWS, and what changes locally
One AWS AI prospecting system reached more than 90% adoption among the employees for who it was built to help. When access expanded to people whose work it didn't fit, adoption settled below 50%. Naturally, if it doesn't fit your role, you don't use it.
AWS adapted by responding with a common measurement approach, peer support to drive usage and leadership training to create top down support and oversight. It also made AI-powered reporting part of weekly and monthly business reviews. Even with those resources, AWS says it still struggles to connect adoption metrics, like usage, and time saved reliably to revenue or customer outcomes (that's a welcome relief for the rest of the economy who struggle to measure ROI!).
A smaller company does not need an extensive champion network or complicated measurement framework. Company-wide usage is misleading when a capability is targeted at one a couple of roles. And training also achieves very little if managers keep prioritising the work that existed before GenAI became a thing in their team's lives.
What it means for the two NZ businesses and how I'd apply the lesson
At the consultancy, I would start with the next six live proposals from one service line, rather than announce a firm-wide rollout, and measure progress in stages.
Before the first proposal, operations would review the previous ten proposals and record how long they took, how much partner rewriting they required and where they stuck in the flow of work.
After each subsequent client conversation, the deal lead would complete a short intake covering the client’s problem, desired outcome, deadline and fee range. AI would prepare the first draft from the approved material uncovered in lesson two.
At the next sales opportunity meeting, the team would open one shared queue showing what is missing from each proposal, who owns the next decision to progress it, and when the proposal is due.
After a handful of proposals, the firm could compare turnaround time and major rework rate with the baseline number (not enough data to judge win rate yet). A far more effective figure than who opened a tool = measuring an outcome for the business, even if it is internal.
At the distributor, I would begin with three salespeople and the previous 30 non-standard quotes.
The baseline would be time from request to quote, pricing corrections and delivery promises that needed a change request due to poor quotation practices.
Each new request would create a shared quote record showing the approved price source, delivery status and owner of any exception.
Finance and operations would receive only the cases needing their judgement.
The weekly pipeline meeting would start with quotes that have waited longer than a day, and the sales manager would ask who owns the delay (rather than who has used the AI tool to help them).
After six weeks, the distributor would compare turnaround times, corrections captured and the share of eligible quotes completed through the new process. It would evolve the use case only if responses became faster without increasing errors.
Same again for example two, we're measuring outcomes, not usage.
Lesson 5 from AWS: Prepare for agents to become part of the team
AWS, and what changes locally
AWS is working towards a state where employees no longer choose between separate agents for account planning, meeting preparation and pipeline analysis, and the capabilities would sit underneath the work they do and appear through systems people already use without having to triggered by the human.
It has built roughly 4,000 internal Model Context Protocol (MCP) servers, which give agents standard ways to reach information and take action. The scale of this architecture makes sense across tens of thousands of employees and a large internal development community.
Neither New Zealand business should recreate that platform. Most can work within their existing stack: Microsoft 365 with Copilot Studio and Power Automate, Google Workspace with Gemini, or ChatGPT Business or Claude Team connected to SharePoint, Google Drive or a CRM. An API connector or MCP server can provide controlled access.
Start with read-only access, restrict permissions by role and log every action. The harder question is what AI may change or send without approval from a human.
What it means for the two NZ businesses and how I'd apply the lesson
Imagine the consultancy uses HubSpot, Microsoft Teams and SharePoint.
When a deal moves to “proposal required” in HubSpot, a Power Automate flow starts.
A Copilot Studio agent reads the opportunity notes and approved case studies from SharePoint, drafts the proposal in Word and posts it to Teams for review.
The partner must approve the scope, fee and claims before anything can be sent.
Imagine the distributor uses HubSpot and Cin7 Core.
When a quote request is created, a Make workflow calls the Cin7 API to check the SKU, customer price and available stock, then writes a draft quote back to HubSpot.
A discount over 5% routes to finance; whereas a delivery promise unsupported by current stock routes to operations.
The quote cannot be sent until the required approval is recorded.
That is the lesson: the agent appears inside normal work, has limited system access and hands commercial decisions to an accountable person. All built through out of the box MCP and API config.
What is worth copying
Taking AWS's lessons at face value would give NZ businesses too much scope, architecture and headache to think about, not to mention the costs required wouldn't measure up to the value delivered.
Useful translation depends on how each company makes money and where its work becomes stuck in the first place (good ole find a business problem first).
For the consultancy, senior judgement is scarce. AI should make the firm’s knowledge easier to access and use while protecting the decisions that require senior level experience and expertise.
For the distributor, coordinating attention is scarce. AI should help information and exceptions reach the right person without turning salespeople into internal couriers.
AWS is solving these problems across almost 40,000 field employees. A New Zealand business can begin with one slow proposal or one quote waiting for three people to reply on and make incremental improvements they feel the effects of within days.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
