How to Roll Out AI Department by Department

Most mid-market companies are now two years into AI and have nothing running in production. Not because the technology failed. Because of how the work was sequenced.

Two patterns produce that outcome, and they look like opposites. One is the enterprise-wide programme: a strategy, a steering group, a platform decision, and eighteen months before anything reaches a person doing a job. The other is the scatter of pilots: six teams trying six tools, each proving something narrow, none of it adding up. Both end in the same place, which is a board asking what the money bought.

The alternative is duller and it works. Take one department. Change two workflows in it properly, with the approval boundaries written down and a baseline captured before you start. Prove it or stop. Then take the next department, carrying forward the plumbing you already built.

Why the big-bang programme stalls

An enterprise-wide AI programme has to make platform decisions before anyone has evidence about which problems are worth solving. So it makes them on vendor material and on which system the loudest team already uses. By the time a real workflow is examined, the architecture is fixed and the workflow has to bend to it.

It also concentrates all the risk at the end. Nothing is in front of a user until late, which means every assumption about data quality survives unchallenged for months. Data readiness is the assumption that fails most often, and it fails quietly. Records look fine in a report and turn out to be unusable the moment something has to match a customer, a contract and an invoice at once.

The third problem is political. A programme that spans every department needs every department to want it at the same time, and they never do. Sales will adopt something that removes work in week one. Finance will adopt nothing until the control question is settled. Forcing a single timeline on both produces a compromise that suits neither.

Why scattered pilots stall too

Pilots fail differently. They usually work, in the narrow sense that the thing does what it was asked to do in a demo, and then they stop. The reason is almost never the model.

A pilot is scoped to avoid the hard parts. It runs on exported data rather than live records, it writes nowhere, and nobody has decided who owns an error. All three of those decisions are the actual project. Deferring them makes the pilot easy and makes the step to production a second project nobody budgeted for.

Six pilots also means six sets of that unbuilt work, six credentials, six places customer data now sits, and no shared context layer. The integration and permission work does not get cheaper by being done six times in parallel by teams who cannot see each other. We have written separately about why one agent is not a strategy, because this is the objection we hear most and it deserves a straight answer rather than a slogan.

The unit that actually works is a department

A workflow is the smallest thing worth changing, and workflows live inside departments. That is not an organisational preference, it is where the dependencies sit. The people who own the process, the people who approve exceptions, the systems that hold the data and the person who gets the complaint when it goes wrong are usually inside one function.

Take one department for a quarter and several things become possible that are not possible across five.

• You can capture a real baseline, because you only have to instrument one set of workflows before anything changes.
• You can write down the approval boundary for every action, with a named owner, and have it reviewed by the person who carries that risk.
• You can train one cohort on one changed workflow, rather than running general AI awareness sessions that change nobody's Tuesday.
• You can stop. A quarter is a small enough commitment that stopping is a normal outcome rather than an admission of failure.

The plumbing built for the first department is not thrown away either. The CRM access model, the context layer, the logging, the review queue and the evaluation approach carry into the second one. That is where the compounding is, and it is the argument against doing four departments badly at once.

What a quarter actually contains

A wave is one department, one quarter, and two workflows taken into production. Two, not ten. The constraint is deliberate: the work that makes an agent safe is not the model, it is the integration, the permission model, the grounding and the evaluation, and that work does not compress.

Enablement and measurement are inside the wave rather than alternatives to a capability. A department that gets two working agents and no training gets two working agents that people route around. A department that gets both and no baseline cannot tell you at the end of the quarter whether to fund the next one.

The full shape, the capability set and what is included is on the AI Accelerator page. It runs from £10,000 per month, committed one quarter at a time, and the quarterly decision is a real one.

Choosing the first department

Do not choose by enthusiasm. The department that most wants to go first is usually the one with the most confident opinions about AI and the least tolerance for the answer being no.

Four questions decide it, and they are worth answering honestly before anyone builds anything.

Where is the cost you can actually name? Not hours saved, which is a number that never appears in the accounts. A decision: a hire not made, a contract not renewed, overtime not paid, agency work brought back in-house. If nobody can name the decision the work would change, start elsewhere.

Can the data support it? Every workflow in this list rests on records being complete enough to match. That is testable in days rather than guessed at for months, and the honest answer is sometimes that the data has to be fixed first.

How bad is a mistake, and who finds out? A wrong internal summary costs an hour. A wrong message to a customer, or a wrong write to a financial record, costs considerably more, and the difference should set the approval boundary rather than being discovered afterwards.

Will the team use it? Adoption is not a change-management problem to be solved after the build. It is a design constraint. People adopt what removes work and reject what adds a review queue, so a rejected suggestion is a defect in the build rather than a failure of the user.

Sales

Sales usually goes first, for an unglamorous reason: the evidence is already in the CRM and the cost of an error is contained, because almost everything a sales agent produces is drafted for a person before it goes anywhere.

The work that pays is preparation and inspection rather than outreach volume. A pipeline review that starts from evidence instead of recall. Meeting preparation and follow-up so commitments reach the record. Stalled deals surfaced before the Monday meeting rather than during it.

The pieces worth reading first are where the approval line sits for a sales agent, which is the question most suppliers leave vague, and what actually breaks when you put meeting notes into the CRM, which is rarely the transcription and usually the identity matching. On pipeline, spotting stalled deals is achievable inside the CRM you already run. If outbound is on the list, read the rules on marketing email and what to configure before you scale anything, because the constraint there is not the tooling.

The full capability set is on AI for sales.

Customer success

Customer success is the highest-value department and the one where the approval question has to be settled first, because the output is in writing, to a customer, under your name.

The instinct is to start with ticket deflection. It is usually the weakest of the four jobs available. Three of them, account review preparation, retention risk and expansion signals, are not deflection at all, and no ticket-deflection product is built for them.

Start with when it should answer a customer at all, which is a policy question rather than a technical one, and note that a model's confidence score is not a control. Then what has to move at handover, so a conversation that reaches a person arrives with its context rather than starting again. Beyond the inbox, churn signals are already in your CRM and expansion revenue sits in existing accounts, neither of which needs another platform.

The full capability set is on AI for customer success.

Marketing

Marketing is where we are most often mistaken for an agency, so it is worth being blunt. We do not write your marketing. We build the systems your marketing team runs on, and what they say with those systems is theirs.

That makes the marketing wave narrower than most vendors would sell you, and more useful. The two things that pay are the reporting layer and the approval layer. On reporting, attribution that explains causes rather than describing outcomes is an engineering problem before it is a marketing one, and there is a documented reason why moving from contact reports to deal reports does not fix committee dilution on its own. On governance, approval gates and an audit trail are what make AI-assisted content defensible, which matters more than any advice about brand voice.

The full capability set is on AI for marketing.

Business operations

Operations carries the highest consequence and, for that reason, the clearest rules. It is also where the standard advice is most wrong. Automate the boring bits is a bad test, because the most repetitive admin work is frequently the most consequential, for the simple reason that somebody wrote a procedure for it.

Document intake is the usual entry point, and the question that matters is where exactly the sign-off gate goes rather than how accurate the extraction is. Chasing money owed to you needs more care than it usually gets, because the obligations depend on who the debtor is. And most requests for a business intelligence platform are actually requests for straight answers out of the systems you already have.

The full capability set is on AI for business operations.

The order is not fixed, but it is not arbitrary either

Sales, then customer success, then marketing, then operations is the common sequence, and the reasoning is risk before revenue. Sales builds the CRM plumbing and the review habit at low cost of error. Customer success reuses that plumbing where the stakes are higher. Marketing depends on the deal-level data being right, which the first two waves tend to expose. Operations is last because it is where an error is hardest to undo.

Plenty of companies should not follow it. If your largest nameable cost sits in the back office, start there and accept the tighter controls. If your CRM data will not currently support a sales wave, fixing that is the first quarter's work and it is a legitimate use of the quarter.

What has to be true before you start

Three things, and they are worth testing rather than assuming.

Records that can be matched. Every workflow above depends on joining a person to an account to a transaction. Where that join is broken, an agent produces confident output about the wrong record, which is worse than no output.

An approval boundary somebody will own. Authority is granted per action, not per agent, and permission to draft is never permission to send. Draft is a perfectly good permanent end state for many workflows rather than a phase to be graduated out of.

A baseline you captured before building. Otherwise the quarterly review is an exchange of impressions. We have written up how to measure whether AI is working, including why time saved is the weakest available claim and what to use instead.

What this looks like when it is real

We have built an order-entry agent for a UK builders' merchant on OpenAI's GPT-5.6, now in staging, that reads incoming orders and writes them into their system. The hire they had budgeted at £20,000 a year was not made.

That is a single workflow in a single department, and it is deliberately the shape of thing we point at. The claim is a hiring decision, which shows up in the accounts, rather than a percentage improvement that does not.

The next step

Start with a diagnostic rather than a platform decision. The assessments on our diagnostics page are short, fixed in scope and carry no obligation, and the AI and Data Readiness Assessment is the relevant one here. It will tell you which department has the nameable cost, whether your records can currently support the work, and where the answer is that you should configure what you already pay for instead of building anything.

If the answer is that you are not ready, that is a useful quarter's finding and a cheaper one than discovering it in month six.