Seven situations, and what we would look for underneath each.

“We bought the licences and nobody uses them.”

AI enablement

What we would look for. Training is the usual explanation. Look at the decision instead. Nobody decided what the tool was for, so everyone tried it once on something it happens to be bad at, decided it was overhyped, and went back to what they knew. With Microsoft 365 Copilot the pattern is specific: the seats get bought, nobody points it at the organisation’s own material in SharePoint, Outlook and Teams, and so it answers much like the free Copilot Chat everyone already had. ChatGPT Business seats and Gemini in Google Workspace go quiet for the same reason. The licences renew every year. The habit never forms.

What we would do first. Find two or three tasks people repeat every week. The dull ones. The Monday figures assembled by hand in Excel, the same six replies retyped in Outlook, the handover note nobody has time to write. Then check the permissions behind those tasks before pointing anything at them. An assistant that can read a folder its user should never have been able to open is a data protection problem, not a productivity win.

What you end up with. One use live and in daily use, a written rule on what may go into Copilot, ChatGPT or whatever arrives next, and a short list of what to do after that in the order it should be done.

“We want to build something with AI and we do not know if it is a real idea.”

AI enablement

What we would look for. Someone senior has seen what these systems can do and is right that there is something here. What is missing is the step between the idea and a thing that runs: whether the data it would need exists in a usable state, whether the answer has to be right every time or only most of the time, and what it is worth if it works. Those three settle most ideas in an afternoon, in either direction.

What we would do first. Write the idea down as a job the software would do, with the input, the output and the person who acts on it named. Then find the cheapest way to be wrong about it: a rough version over real data, not a demonstration over invented data. Most ideas change shape at that point, and a few turn out to be a report or a form rather than AI at all. We would rather find that out in week two than in month six.

What you end up with. A straight answer on whether it is a real idea, what it would cost to build, and what has to be true about your data and your permissions first. If it is real we build it, on your systems, with the review points and the record designed in. If it is not, you have saved the budget and you know why.

“Staff are pasting things into ChatGPT and nobody has said what is allowed.”

AI enablement

What we would look for. People found something useful before anyone got round to writing a rule. It is rarely only ChatGPT. There will be Gemini in somebody’s personal Google account, Claude on a phone, Copilot Chat in the browser because it was already sitting there, and at least one thing nobody has heard of that a supplier recommended. Banning it does not work. It moves to personal phones, where you cannot see it at all. And the tool itself is rarely the real exposure. The exposure is that nobody knows what has already been put into one, or whether the account it went into belonged to the company or to the person.

What we would do first. Establish what is being used, and for what, with no blame attached. Sign-in records in Microsoft Entra ID, or the equivalent in the Google Workspace admin console, will show you what people have signed into with a work account. That is about half the picture. The half that matters is the free personal accounts no log can see, and you only get those by asking. What you need here is the truth, and the way you ask determines whether you get it or get a confession.

What you end up with. A one-page rule people can follow, a sanctioned route for the things they were doing anyway (a company workspace on ChatGPT Business, Microsoft 365 Copilot or Claude Team, where your content is not used to train the model and an administrator can at least see the account exists), and a named person who approves a new use.

“Nobody is quite sure who can see what.”

Data protection review

What we would look for. Years of accumulated access. A SharePoint site inherited through a reorganisation, a folder set to ‘anyone with the link’ to hit a deadline four years ago, a Teams team created for a project that finished long ago and still holds its files, leavers who kept a group membership in Entra ID, a supplier still sitting in a shared mailbox. On Google Workspace it is the same story told through shared drives and link sharing. None of it was a decision. All of it is now the position.

What we would do first. Map effective access, not intended access: what a real account can open today, whatever the policy says it should be able to. In practice that means the sharing reports in the SharePoint admin centre, group and guest membership in Microsoft Entra ID, and the matching view in the Google Workspace admin console. Where Microsoft Purview is already licensed we will use it to find the sites holding sensitive material that far too many people can reach, though the finding usually arrives well before the tooling does.

What you end up with. An access map, a list of what to close and in what order, and an owner against each decision, written in terms of the groups and sites your own tenant uses so somebody can act on it in Entra ID on a Tuesday afternoon. Almost everything else depends on this, so it comes first.

“Everything goes through one person.”

Workflow automation

What we would look for. A process that was never designed. It accreted around whoever turned out to be good at it, and it now lives in their Outlook inbox, a spreadsheet on their own OneDrive, and a set of rules they have never had to say out loud. It works perfectly until they take leave. Nobody has written it down because the person who could write it down is the bottleneck.

What we would do first. Sit with them and record what they do. That includes the judgement calls, which appear in nobody’s documentation and are the reason the process works at all. This part is deliberately toolless. Deciding it will be Power Automate before you have watched the job done once is how organisations end up automating the wrong half of it.

What you end up with. The routine parts running as a workflow (Power Automate where the organisation is already on Microsoft 365, Google Apps Script or n8n where it is not), the approval landing in Teams or Outlook where the approver already spends the day, and every run leaving a record in a SharePoint list you can point at when somebody asks what happened. The judgement parts stay with a person and are named as such, and the process is one a second person could pick up.

“Three teams give three different answers to the same question.”

Pain-point audit

What we would look for. Everyone assumes a disagreement about meaning. That is what the meeting ends up being about. Check the cheaper cause first. The three answers came from three places: a Power BI report that refreshed at six this morning, an Excel extract somebody pulled last Thursday, and a number read straight off a screen in the CRM or the finance system. Or one query excludes something the other two keep.

What we would do first. Run all three against the same point in time, which usually starts with checking when each Power BI report last refreshed and when that spreadsheet was exported. If the figures then agree, the problem was scheduling and not definition. A completely different fix, and a much cheaper one.

What you end up with. One definition per figure with a named owner, the thing that produces it (a measure in the Power BI semantic model where there is one, a documented SQL view where there is not), and a record of every report and board pack it appears in. The next disagreement then takes an afternoon instead of a quarter.

“We ran the training and nothing changed.”

Training and embedding

What we would look for. Training that taught the tool and not the job. The session demonstrates Copilot assembling a slide deck to a room of people who never make slide decks: they live in Outlook, in Excel, and in one system that was not mentioned once all morning. People follow along happily, working through the trainer’s example. Then they sit down on Monday in front of their own work and cannot see where any of it applies.

What we would do first. Find the two or three moments in an actual week where the new way would be used, and build the session entirely around those: your own inbox, your own spreadsheet, your own records in SharePoint or wherever they sit. If a room of eight people cannot each name one thing they will do differently that week, the session has not worked, whatever the feedback form says.

What you end up with. Short role-based checklists written for the tools each role opens (Outlook and Excel for one team, Teams and SharePoint for another), sessions run on your own systems, and a named person in each team who owns it after we have gone. There is no certificate at the end of it. What people leave with is their own work, done a faster way.