Five pieces of work.

Start here: where AI would pay

Pain-point audit

Two to three weeks. An hour or so each from the people whose work we follow, arranged around them.

Before we put AI anywhere near your work, we find where the time and the risk go. Not where you think they go, and not where the process document says they go. We sit with the people doing the work and follow what happens: the spreadsheet nobody mentions, the approval that happens by text message, the two days a month somebody spends reconciling one report against another. That is where the candidates for AI and automation come from, and we start here instead of with a tool.

Some of the answer is always about data, so the audit follows that too. What moves through each process, who can reach it, and what would have to be true before any of it could safely be automated.

You receive

• The processes that cost you most, ranked, with the hours attached
• Where each one leaks time, and whether the cause is people, process or permissions
• Findings in plain language, ranked by risk and by effort
• A first-ninety-days list with a named owner against each item
• What you already pay for and are not using, set against what you were about to buy
• A definition for any figure you report on: what it means, what produces it and who owns it
• A shortlist of where AI would earn its place in your organisation, and what each one would take
• A straight answer on which of the services below you need, and which you do not

What makes the AI defensible

Data protection review

Stands alone, or follows the audit.

AI tools reach across whatever your access model lets them reach, so this is the work that decides whether anything you switch on afterwards holds up. We follow the data through its actual life cycle rather than through the policy: where it enters, where it gets copied, who it is shared with, where it comes to rest. Most of that distance, between the documented position and the real one, is what the review is looking for.

You receive

• A record of what you hold and the reason for each item
• An access map: who can open what, and who no longer should
• Your retention position, and where it is silent
• Each gap written as a specific checkable statement, with an owner and a control
• Controls written as procedures people can follow, not policy prose
• A register of decisions: what was decided, by whom, on what basis

The register matters more than it sounds. What goes wrong later is rarely a bad decision. It is a decision nobody recorded, so six months on everybody argues it out again from the start, with different people in the room. Once AI is in the picture, that record is also how you answer the question of who approved this and on what basis.

Getting AI working

AI enablement

From a first use to a fourth. The shape of the problem matters, not how far along you are.

This is the work of getting AI from talked about to in daily use. The hard part is not the technology. It is not knowing which use is worth doing, or whether you are allowed to, or how to tell a real use from an expensive demonstration. We settle all three and take one use live, so there is something running at the end of it and not a slide pack.

We do not lead with a product. Which tool it ends up being is close to the last decision we make, and we look at what you already license before we look at anything you would have to buy. Where the suite assistant is the wrong shape, that can be a model reached directly through its API, or an open-weight model run inside your own tenancy when the data cannot leave at all. Agreed in writing before anything is pointed at your data.

Choosing between them is a piece of work rather than an opinion. We take one real task, run the candidates over a sample of your own material, agree what counts as good enough before anyone looks at a result, and write down what we found, including whatever did not separate. Sometimes the conclusion is that the job wants a form or a report rather than AI.

You receive

• Where AI would help in your organisation, and where it would not, with the reasoning for both
• What has to be true first: permissions, records and who is accountable
• A written rule on what staff may and may not put into an AI tool, and who approves a new use
• One use taken all the way live, chosen for being useful and not for demonstrating well
• An assistant that answers from your own handbooks, policies and records, where that is the use, with the access limits agreed first
• Your people shown how to use it in their actual work, on your systems

We will tell you when the honest answer is not yet, because we want the thing we build to outlast us. If nobody has reviewed your access model in years, fix that before you switch on anything that can search across everything at once. Then switch it on. Most of that is quick, and we say so in week one rather than let you find out later.

Putting AI to work on the repetitive jobs

Workflow automation

One workflow at a time, live before the next one starts.

We take one named administrative burden and rebuild it, with AI and automation carrying the repetitive part and the controls settled before anything is built. Getting what you need out of documents, forms and inboxes, moving it between the systems that need it, and writing back a record of what happened. Where a job needs judgement across several systems, that can be an agent rather than a fixed flow. It runs on tools you already license wherever it can, so the data stays where its governance already sits. The approval lands where that person already spends the day, which is most of the reason these things get used at all.

You receive

• The workflow in production, with a person checking at every point where the software decides something
• An access model: who may run it, who may see the output, what it may never touch
• A record of what the automation did, so the process stays auditable
• A handover pack: how it works, how to change it, how to retire it
• An off switch that works, and someone named who may use it

Permissions are always inherited from the underlying system. We never reimplement them. Nothing we build can surface a record its user could not already have opened by hand.

So the AI survives without us

Training and embedding

Delivered on your systems, not a demonstration tenant.

AI only pays back when the people doing the work use it, and use it within the rules. So: guidance and sessions built from your own controls, your own AI tools and your own workflows. Comprehensiveness is not the test. The test is whether somebody reads it on a Tuesday and does the right thing on the Wednesday.

You receive

• A short handbook, and role-based checklists for the people who need them
• Sessions run in small groups, in person or online, using your real cases
• How to ask, and how to tell whether the answer is good enough to act on
• A named internal owner for each thing we hand over
• A session for the people accountable rather than the people operating: what has been decided, what is still open, and what they are signing off when they approve a new use

This stage is what makes the handover real rather than a document nobody opens.