AI demos have perfect posture because somebody removed every awkward detail.
The sample customer has a complete record. The invoice number is in the right box. Nobody interrupts. The Wi-Fi behaves. Every approval happens in the expected order.
Then the tool meets Friday afternoon.
A customer replies from a different email address. Finance has already changed the account code. The person who normally approves refunds is collecting a child from school. Someone pastes two requests into one message, and the old system slows everything down.
That is the test I care about.
After 27 years in technology, I have learned that the awkward case tells you more than the polished demo. If an AI workflow can help a tired team finish real work at four o’clock on Friday, it may deserve a place in the business. If it needs perfect inputs and constant rescue, another licence will not fix it.
AI adoption is growing, but depth still matters
The Office for National Statistics reported in July 2026 that self-reported AI use among UK businesses with 10 or more employees had risen from about 12% in late 2023 to about 35% in 2026.
The same analysis called adoption relatively shallow. The average adopting business used about 1.6 AI technologies, up from 1.4 in late 2023.
That feels familiar. Plenty of firms now have an AI writing tool, a meeting assistant or a feature bundled into existing software. Fewer have changed a complete business process around it.
A second government study makes the commercial gap clearer. Department for Science, Innovation and Technology research published in January 2026 found that 77% of businesses using AI reported no change in revenue after adoption.
A tool can save somebody ten minutes and still make no visible difference to the business. The saved time may disappear into checking, copying, correcting or waiting for the next person. A smart first step can leave the rest of the process exactly as slow as before.
The Friday afternoon test
Friday afternoon is useful because the business has stopped pretending to be a diagram.
People are finishing work from the whole week. Exceptions have accumulated. Patience is lower. The tidy workaround from the project meeting has met customers, suppliers, missing data and competing priorities.
I would rather observe an AI pilot in that environment than watch another rehearsed presentation.
Pick one workflow that happens often and irritates the people doing it. Handling a sales enquiry. Checking a supplier invoice. Preparing a quote. Chasing missing order details. Turning meeting notes into actions. Choose one, not the whole department.
Then run five real cases through it. Remove or mask personal and confidential data where the tool has not been approved to receive it. Do not correct the cases before the test. Keep the odd formatting, the incomplete answer and the request that does not fit the normal route.
Watch where the work stops.
Does the AI know when information is missing? Can a person see what source it used? Does it pass the result into the next system, or create another copy-and-paste job? What happens when its confidence is low? Can somebody correct it without starting again? Who approves an action that affects money or a customer?
Those questions expose the cost hidden by the demo.
Measure the whole hand-off
Most AI pilot measures start and finish too early.
A team times how quickly the tool drafts an answer. It does not time the review, the correction, the transfer into the CRM or the wait for approval. The result looks fast because half the work sits outside the stopwatch.
Measure from the moment the work arrives to the moment the next person can use the result. Include the human checks. Include failures and rework. Include the time spent finding missing information.
For a small pilot, I would record six things:
- Total time from arrival to a usable outcome.
- Minutes of human effort inside that total.
- Cases completed without correction.
- Cases sent down the wrong route.
- Exceptions the system could not handle safely.
- Time spent moving information between tools.
You do not need a complicated dashboard. A spreadsheet and ten honest cases can be enough to stop a poor purchase or justify a sensible one.
The comparison also needs a baseline. Run the same cases through the current process first. Otherwise, a quick AI result can look impressive while being slower than the experienced person it is meant to help.
Buy the common part, fix the distinctive part
The Friday test also helps with the build versus buy decision.
Buy standard capability where your work is standard. Transcription, document search, first-draft writing and routine classification are available in many products. A UK SME rarely needs to build its own model for those jobs.
The difficult part is usually the join between the tool and the business.
Your quote may depend on a pricing rule stored in an old database. A supplier invoice may need different approval based on project, amount and contract. A customer request may cross sales, operations and finance before anybody can close it. That logic is specific to your company, even when the AI feature is common.
Start with configuration. Use the workflow tools and integrations already available in your systems. Add a small connection where information has to move reliably. Consider bespoke software only when the process creates real commercial advantage or the existing products force people into repeated manual work.
A custom build should earn its cost by removing a measured constraint. It should not exist because the demo looked clever.
Give the pilot a safe failure route
An AI workflow needs a boring way to fail.
If it cannot classify a request, it should put the case in a named queue. If required information is missing, it should ask for it or hand the case to a person. If an action changes money, access or a customer commitment, the approval must be clear.
Do not let uncertainty turn into silent automation.
Keep the first scope narrow. Give the tool the minimum access it needs. Record what it did. Make it easy to pause without stopping the rest of the business. The purpose of a pilot is to learn where the system works and where it does not.
A useful test shows you the boundary before a customer finds it, even when some cases fail.
What I would do before Monday
Choose one process before everyone disappears for the weekend. Ask the person who does it regularly to bring five genuine cases on Monday, including the one they normally hate.
Write down the current time and the points where work waits. Agree what the AI may do, what a person must approve and where a failed case goes. Then test the complete hand-off, not the attractive first thirty seconds.
If it saves time across the whole workflow without adding risk or hidden checking, expand it carefully. If the benefit vanishes when the inputs get messy, fix the process or stop the pilot before buying more licences.
Friday afternoon will tell you which one you have.