Our staff already ignore one dashboard. Why would this be different?
Because it is not another dashboard. The work here is putting the intelligence where the decision already happens: inside the approval screen, on the order the buyer is looking at, in the routine that runs before the shift starts. Anything that requires a person to remember to open a separate tool competes with their actual job and loses.
What is a realistic first project?
One process, chosen because it is high volume, well understood and currently done by hand. Invoice matching, first-line ticket triage, and the weekly report somebody rebuilds every Monday are the usual candidates. Small, measurable and finishable matters more than important, because the second project is funded by the first one working.
Will this replace jobs?
The honest answer is that it changes what those jobs contain. The work that goes first is the copying, the checking and the chasing, and what is left is the judgement, which is generally the part people were hired for. Where a change genuinely reduces headcount need, saying so early is better than discovering it during rollout.
How do you handle the cases the automation gets wrong?
By designing the exception path first rather than last. Every automated step has a defined way to escalate to a person, with the context attached so that person is not starting from nothing. The measure of a working automation is not that it never fails, it is that its failures are visible, routed and rare.
Several departments have bought their own AI tools. Should we stop them?
Not by banning them, because a ban moves the same activity onto personal accounts and personal phones, where you have no visibility at all and no ability to delete anything afterwards. Start by counting what exists. Expense claims and a frank half hour per department usually turn up more than IT expects, including at least one place where customer data is going into a consumer account with no agreement behind it. Then sanction a small set, pay for it properly so the approved route is faster and better than the unapproved one, and name two or three red lines you will genuinely enforce rather than twenty you will not. The reason a department went and bought something is that it had a problem and nobody offered it an answer. That is information worth having, not a disciplinary matter.
When the output is wrong, who is accountable?
The same person who would have been accountable without it, which is the answer nobody enjoys and the only one that survives a complaint. A regulator, a customer or a court will not accept that the system decided. They will ask who put it in, who signed the output, and who was meant to be checking. So we make that explicit rather than implicit: a register of the places where this touches a customer, a payment or somebody's employment, with a named role against each and a note of what that person is expected to check. The useful side effect is that it prices the decision honestly. If nobody is willing to put their name to a whole category of output, that is a clear signal it should be drafting for a person rather than acting alone.
Should we build this capability internally or keep depending on a partner?
Both, with an expiry date on the dependency, and the test is concrete: can your own people change a threshold, add a document source or switch something off without raising a ticket with us. If not, you have bought an outcome and rented the understanding, and the price of that arrangement only goes one way. The roles you actually need are smaller than the job adverts suggest. An owner per process who is answerable for what it produces, somebody who can look at a change and say whether it helped, and a manager willing to retire the manual version on a date. That is usually three people you already employ with some time protected, not a new department. We would rather write the handover into the engagement than be quietly necessary in year three.
Our board wants an AI strategy. Where does that actually start?
With a list of decisions, not a list of tools. A strategy that names products ages the moment the market moves, and it tends to be written by whoever sat through the most vendor briefings. The version that survives contact is duller: which decisions and repeated tasks does this organisation perform in volume, what does a wrong answer cost in each case, and which of them is written down well enough for software to work from at all. Sequence by cost of error rather than by enthusiasm, so the first two live cases are high volume and forgiving, and the customer facing or regulated ones come after the organisation has learned something. Then put a name against each. A strategy no individual is accountable for is a slide deck with a budget attached.
