Service Design Is Back. This Time, It Builds the AI

Why do most AI projects fail to pay off?

The most quoted figure comes from MIT's Project NANDA. Its July 2025 report, The GenAI Divide, found that 95% of the organisations it studied were getting no measurable return from their generative AI investment. Only about 5% of custom enterprise tools reached production.

The report's explanation is the useful part. It says the failures were mostly not about model quality or regulation. They came from brittle workflows, tools that don't learn the context they work in, and a poor match with how the business actually runs day to day.

It is worth being careful with the number. The report calls its own findings preliminary, and it rests on a review of about 300 public AI projects, interviews with people from 52 organisations and a survey of 153 senior leaders. It is a strong signal, not a census.

The people doing the deployments say something similar. At HumanX in Amsterdam in September 2026, Colin Jarvis, who leads OpenAI's forward deployed engineers, said that in about 80% of cases the problem is deployment, not the model: companies don't yet know how to roll AI out, govern it or prove they can trust it.

What is a forward deployed engineer?

A forward deployed engineer is someone an AI company places inside a customer's business to get its technology working in that business's real conditions. The pattern usually runs like this:

• Watch before building. Sit with the people doing the work and find where the time actually goes.
• Fix the real bottleneck. In the claims example, a system that reads every document in a claim and drafts the summary the adjuster used to type by hand.
• Prove it on real cases. Build a test set with the most experienced staff, for example 200 past claims with the correct answers, and grade every improvement against it.
• Hand it over. Build it with the customer's own team, inside their own systems and security boundary, so it keeps running after the engagement ends.
• Feed back. Send what was learned back to the product team.

According to The Next Web's report of Jarvis's talk, every OpenAI engagement starts with a two-day visit where business leaders are asked to ignore AI and name the biggest levers in their business. His team now hires more domain experts than it used to, and he described their role plainly: "we should always be temporary." The same report notes that AWS and Microsoft are both investing heavily in the same model.

Read that list again without the word "engineer" and it describes a service design project.

What is service design?

Service design is the practice of understanding and improving how a service is actually delivered: not just what the customer sees, but everything behind it that makes it work. It grew out of marketing and operations research in the 1980s and became a design discipline in its own right in the 2000s.

A few ideas carry most of the weight:

• The service blueprint. G. Lynn Shostack introduced it in 1982 and set it out for a wide audience in the Harvard Business Review in 1984. It maps what the customer experiences, the work done out of sight to deliver it, and the handovers in between. Mary Jo Bitner and colleagues later turned it into a practical technique that companies still use.
• Frontstage and backstage, divided by a "line of visibility". What the customer sees sits above the line. The staff, systems and processes that support it sit below.
• Contextual inquiry. Hugh Beyer and Karen Holtzblatt's method of watching people do their real work, in their real place, and asking about it as it happens. What people say they do and what they actually do are rarely the same.
• Value is created in use. Stephen Vargo and Robert Lusch argued in 2004 that value isn't delivered in a product. It is created when a customer uses it in their own context. A tool nobody uses has no value, however clever it is.
• Diverge, then converge. The Design Council's Double Diamond, first published in the mid-2000s, describes exploring widely to find the right problem before narrowing down on the right solution.

What did service design used to do?

For most of its history, service design produced understanding for people. The output was a blueprint on a wall, a journey map, a set of recommendations and a redesigned process. It helped hotels, banks, hospitals and councils see where their service broke down and fix it.

It was valuable, and it often had a weakness: the map was the deliverable. Whether anything changed depended on someone else picking it up and building it.

How does each technique translate to building AI?

This is where it gets interesting, because every classic technique now has a direct job in an AI project:

• Contextual inquiry becomes finding the real task. Watching the adjuster is contextual inquiry. It is how you find out that the job isn't "assess claims" but "stop retyping the same details three times".
• The blueprint's backstage becomes the system's map. The layer below the line of visibility, the systems, spreadsheets, handovers and people who hold knowledge, is exactly what an AI system has to connect to. The blueprint is no longer just a picture. It is the specification.
• The line of visibility becomes the line of access. Deciding what the customer sees has turned into deciding what the AI may read, what it may say, and to whom. Some knowledge stays inside the business. An approved part goes outside, where AI assistants describe you to customers.
• Service prototyping becomes the test set. Walking through a service before launch is the ancestor of testing an AI system on real past cases with known right answers.
• Co-design becomes handover. Designing with staff rather than for them is what makes a system survive after the consultant leaves.
• Value in use becomes the measure of success. Jarvis said the companies that succeed judge AI by production use, not proofs of concept. That is service-dominant logic, forty years later.

Why is it back through a different lens?

Two things have changed.

First, the map is now the build. The knowledge a service designer used to capture for a report (how quotes are really written, which customer gets which credit terms, who approves discounts) is now the material an AI system runs on. Written down properly, it becomes a business knowledge base: one checked place that both staff and AI assistants work from.

Second, there is a new audience. Customers now meet many businesses through an AI assistant's answer first. The same captured knowledge, the approved part of it, is what lets those assistants describe the business accurately. I wrote about that side in Your Brand Identity Is Now a Dataset.

So the discipline hasn't changed much. Its output has. It used to end with a map for people. Now it ends with a working system and a source of truth for machines.

How do I apply it?

Every piece of work I do follows the same five steps, and they will look familiar by now:

1. Shadow. Sit with the people who do the work and watch where the hours go.
2. Map. Trace how information moves, and find the one or two places where a fix pays back fastest.
3. Build. Build the assistants and automations around the real workflow, connected to the tools the business already uses.
4. Prove. Build a test set of real past cases with the most experienced staff, and grade every version against it.
5. Hand over. Set it up in the client's own account, train their team to run it, and step back.

In the Caribbean, I do this work through UX Caribbean, where it is offered as the Business Knowledge Base and the AI Operating System.

What should you ask before buying an AI product?

• Who will spend time with the people who actually do this work, and for how long?
• What exactly is the problem it fixes, in hours or errors, and how was that measured?
• How will we know it works? Is there a test on our own real cases?
• Where will it run, and who can see our data?
• What happens when the supplier leaves? Can our own team run and change it?

If the answers are vague, the pilot will probably join the 95%.