Clients arrive at an AI automation studio with a fairly consistent request. They want the thing they have read about: an assistant, a chatbot, something conversational sitting on top of their data. It is a reasonable place to start and it is almost never where the value is.
Here is what a year of BUILD Studio engagements actually looks like, including the parts that do not photograph well.
What clients ask for
The request is usually a surface. A chat interface for the support team. A tool that drafts the proposals. Something that reads the PDFs.
These are real requests and we build them. But when we trace the actual cost back through the business, the interface is rarely the expensive part. The expensive part is that the data the assistant needs lives in four systems that disagree with each other, that nobody owns the definition of a "customer", and that the process the assistant is meant to accelerate has three undocumented exceptions everyone works around by asking Grace, who has been there eleven years.
You can put an assistant on top of that. It will demo beautifully and then quietly stop being used.
What they should be asking for
The engagements that change a number on the P&L tend to start somewhere less exciting: pick the one workflow that everybody complains about, map what actually happens rather than what the process document says, and automate the specific, boring middle of it.
Invoice matching. Rider onboarding. The weekly report that three people assemble by hand from two exports and a WhatsApp thread. None of these are AI-shaped problems in the way the marketing suggests. All of them have a step in the middle — read this unstructured thing, decide which bucket it belongs in, flag the ones that are ambiguous — where a model is genuinely better than a rule, and where the rest of the plumbing is ordinary software.
The AI is often ten per cent of the build. The other ninety per cent is the integration work that makes the ten per cent reachable. Clients are sometimes disappointed to hear this. The ones who ship are the ones who hear it early.
The plumbing decides everything
The unglamorous conclusion after a year of this: the determining factor in whether an engagement lands is almost never model choice. It is whether someone on the client side owns the data, whether there is a person whose job gets visibly better, and whether we agreed up front what "working" means in a number.
Where those three are true, the project survives contact with the organisation. Where they are not, we have built things that were technically correct and organisationally homeless.
That is also why our teams are structured the way they are. The engineering team sits in India, the design and operator layer in Accra, client-facing work in London. It sounds complicated. In practice it means the person mapping the workflow has actually run a workflow, and the person building it has built this kind of thing before — which is the combination that keeps the ten per cent from drowning in the ninety.