Start with one team

It depends on where there is useful work to change and a team able to own the change. Start with a repeated workflow whose inputs and outputs you can inspect, where time or errors matter, and where a named person can approve a trial. Measure the current version before building anything. Agree what people will review and what AI may do, then test a small version on real work using approved tools and data. If the result is better, decide what to expand. If the main blocker is access, security or an unclear owner, address that before starting the build.

We would start with work that happens often enough to learn from. Something with a recognisable beginning and end, and a team that can tell you when the result is wrong. Recurring reporting or first-pass document review are possible examples. Neither is automatically a good candidate: the data, review needs and cost of a mistake can make the answer very different.

Talk to the people doing it. Watch where they copy information, wait for someone else or remake the same decision. The process on a slide is a starting point, but the small workarounds often explain where the time actually goes.

Starting small does not mean leaving the team to invent the company's position on AI. Leadership needs to decide what people should own, what the team is allowed to try and what would count as a useful result. The team needs room to work out how that applies to its workflow.

That distinction matters. A company-wide training programme can introduce the tools. It cannot, on its own, decide who signs off a report, what evidence is required or when an AI draft is safe to use. Those choices belong in the work.

Write down the baseline and the review standard first. Include the time spent checking and fixing the output, not only the time spent producing it. Keep a way to return to the old workflow while the new one is being tested. Someone should be responsible for stopping the trial if it is not good enough.

The first version does not need to be a new platform. It needs to answer whether this way of doing the work is worth taking further. A prototype that exposes a bad assumption is useful too, provided you learn that before committing to a wider rollout.

Once there is something specific to carry forward: a measured result, a review practice that held up, and an owner who understands what has changed. Then choose the next workflow on its own merits. Do not assume a good result in one team means the same setup belongs everywhere.

The models and tools will keep changing. We think the company needs a regular habit of asking what is possible now and which parts of its work should be reconsidered. One team is a place to start learning that habit, not a limit on the ambition.

Tell us which team and which workflow you have in mind. Start a conversation, or read how we work and what it costs.

Still deciding where to start? Compare consultancy, training and building in-house.