Theatre

A company rolls out AI to several thousand employees. The licences are live. Staff attend prompt workshops. A network of enthusiastic “AI champions” appears. Six months later, management receives a dashboard full of active users, generated summaries and estimated hours saved.

The dashboard proves that people opened the software. It says very little about productivity.

Did the company process more orders? Did customers receive answers faster? Did error rates fall? Did the backlog shrink? Did anyone remove a step from the process?

If nobody can answer those questions, the company has built productivity theatre.

The pattern is common because it is easy. Buy a tool, place it on top of existing work and count the activity. Every approval, handover, spreadsheet, status meeting and copy-and-paste exercise remains in place. The process looks more modern while behaving almost exactly as it did before.

AI may produce a better first draft or find information faster. Useful, yes. Fivefold improvement, no.

The maths is rude

Imagine a workflow requires 100 minutes of active work. Drafting accounts for 20 of those minutes. AI cuts the drafting time in half.

The workflow now takes 90 minutes.

A task improved by 2x. The full process improved by 1.11x.

This is where many impressive AI presentations fall apart. A dramatic improvement inside one small task produces a marginal improvement across the whole workflow.

A fivefold gain means reducing those 100 minutes to 20. A tenfold gain means reaching 10. Faster writing cannot remove 80 or 90 minutes when writing only accounted for 20 in the first place.

Large gains require entire portions of work to disappear. Lookups, handovers, transcription, routing, repeated checks and avoidable rework all have to come under examination.

That work is less exciting than watching a chatbot produce a proposal in eleven seconds. It is also where the money is.

Choose a workflow, not a department

“AI for Legal” is too broad to measure. So is “AI for Marketing” or “AI for Finance”.

Choose a completed unit of work:

• Review an incoming contract against the company playbook and prepare it for counsel.
• Resolve an inbound support request within an approved policy.
• Process an invoice from receipt through validation and posting.
• Turn approved product information into finished listings for each sales channel.

Each begins with a defined input and ends with an accepted output. That boundary makes the work measurable.

Consider contract review. Giving a lawyer a chat window may speed up the first reading. The lawyer still has to find the correct playbook, compare individual clauses, check earlier decisions, draft alternative language, contact the business owner and record the outcome.

A redesigned workflow goes further. The contract enters through a structured intake. The system selects the correct policy, extracts the clauses and compares them with approved positions. Each issue arrives with the relevant source, the proposed language and an indication of uncertainty. Counsel reviews the exceptions, makes the decision and records it once.

The lawyer keeps responsibility for the judgement. The system handles retrieval, comparison, preparation and documentation.

Whether this produces a threefold or eightfold gain depends on the starting point, the quality of the source material and the number of exceptions. The mechanism is clear: several steps have disappeared.

Customer support follows the same logic. Drafting a polite reply saves a little time. A larger gain becomes possible when the system can retrieve the correct order, check the policy, prepare or perform an approved action, update the customer record and send unusual cases to a colleague.

Text generation is one part of that workflow. Permissions, data access, decision rules and exception handling do most of the heavy lifting.

Large gains need demanding conditions

A workflow with fivefold potential usually has several characteristics.

First, it happens often enough to measure. Rare and highly individual decisions make poor early targets. Repeated cases with a recognisable structure give the team enough evidence to improve the system.

Second, the organisation knows what an acceptable result looks like. If five experienced reviewers give five different answers, the team has a policy problem before it has an AI problem.

Third, the required information is available and current. A model cannot compensate for three conflicting policy documents, missing customer records or product data last updated during the Obama administration.

Fourth, the system can complete approved actions. A text generator leaves every click, validation and system update with the employee. Narrow permissions allow the system to complete low-risk steps while routing exceptions to a person.

Fifth, uncertainty has somewhere to go. The system should show its sources, signal weak conclusions and hand unusual cases to someone with the authority to decide. A confident-looking answer is not a control mechanism.

Sixth, one person owns the result. That owner needs authority over the process, the policy and the measure of success. An IT team can deploy software. It cannot remove a legal approval, change a refund limit or settle an argument between two departments on its own.

This is why AI adoption is largely a management task. Technology provides new options. Management decides whether the organisation changes how work gets done.

Measure finished work

Licence activation, prompt counts and generated words are implementation statistics. They help the team see whether a tool is being used. They cannot settle the business case.

Track measures tied to finished work:

• Median time from input to accepted output.
• Active human time per completed case.
• Completed and accepted cases per week.
• First-pass acceptance.
• Rework and error rates.
• Percentage of cases sent to a person.
• Cost per completed case.

Quality and risk must sit beside speed. Processing ten times as many invoices while doubling the error rate is an expensive way to create a second project.

Treat self-reported hours saved as a discovery signal. A financial return requires a visible change. Capacity increases. A backlog falls. Customers receive answers sooner. External spend declines. Errors become less frequent.

Otherwise, the organisation has created theoretical time. Theoretical time has never signed a purchase order.

Prompt training has a ceiling

People should learn how to use the tools available to them. Better prompting can improve local tasks and reduce frustration.

It cannot decide which approvals should disappear. It cannot repair conflicting policies, connect missing data or give a system permission to issue a refund. Those are operating decisions.

Hackathons and internal competitions can help discover promising uses. Production begins when someone takes responsibility for one measurable workflow and works through all the boring details: access, exceptions, controls, ownership and what happens when the model is wrong.

A clever demonstration shows that something may be possible. A working process survives ordinary data, rushed employees, unusual cases and Monday morning.

Watch what happens to the human job

A workflow can become five times faster while the remaining human work becomes more demanding.

Once the easy and repetitive cases disappear, employees spend more of their day on exceptions, ambiguity and unhappy customers. That work requires concentration and judgement. It may also be more tiring.

Managers need to redesign roles alongside the process. People may need better training, more authority, different performance measures and enough variation in their day. Fivefold throughput should not become fivefold cognitive stress.

This also affects trust. Employees will resist a programme that measures every action, conceals its effect on staffing or expects them to repair machine errors without giving them control. Honest communication is part of implementation.

Start with twenty real cases

Pick one workflow. Take a set of recent cases and map what happened from start to finish.

Record every lookup, handover, wait, approval, repeated check, copy-and-paste action and correction. Establish the baseline. Then ask which steps can disappear, which decisions can follow an approved rule and which exceptions require human judgement.

Run the redesigned workflow on real cases. Compare accepted outputs, time, cost, errors and exception rates against the baseline. Keep the permissions narrow until the evidence supports expanding them.

Start with one workflow and name one owner. By the end of the first week, that owner should have a baseline from real work. Before buying another licence, the team should be able to say which steps will disappear and how the finished output will be measured.