Let me tell you about an engagement we turned down last year.
A mid-sized consulting firm - around 200 people, good reputation, growing nicely - came to us wanting to roll out AI across their entire research function. They'd seen a vendor demo, the managing partner was excited, and they had budget approved. They wanted to start immediately.
We said no. Or rather, we said "not yet." Their data was scattered across four disconnected systems, they had no governance framework for reviewing AI outputs, and nobody had actually mapped whether the research bottleneck was where they thought it was. If we'd taken the engagement, we'd have billed well. And twelve months later, they'd have had an expensive tool that nobody trusted and nobody used.
That conversation - the willingness to say "you're not ready for this yet, and here's specifically why" - is probably the best summary of how we approach AI at Distinction. It's not glamorous. It doesn't make for exciting vendor demos. But it's why the AI engagements we do take on actually deliver measurable outcomes rather than gathering dust.
If you've read some of the other pieces I've written about AI - why pilots fail, how to think about readiness, what agentic systems actually look like in practice - you might be wondering whether this is genuinely how we operate or just how we write. Fair question. This is my attempt to answer it directly.
These aren't aspirational. They're operational commitments. Every one of them has, at some point, cost us revenue. I'm fine with that.
Start with the problem, not the technology. Most AI conversations start in the wrong place. A partner reads an article, sees a competitor's announcement, attends a conference panel - and the question becomes "how do we use AI?" instead of "what's actually slowing us down?" We always start with the workflow. I remember a legal firm that came to us wanting document review automation. Reasonable enough - document review is tedious, time-consuming, and expensive. But when we mapped the process, the review itself took two hours. The approval workflow afterwards took two weeks. Automating the two-hour task while leaving the two-week bottleneck untouched would have been a spectacular waste of money. We fixed the approval process first. Six months later, there was a genuine case for AI-assisted review. But not before.
Radical transparency on what AI can't do. This one makes some clients uncomfortable, honestly. When someone's excited about AI-powered legal research, they don't always want to hear that current models hallucinate citations - they invent cases that sound plausible but don't exist. In a regulated environment, that's not a quirky limitation. It's a liability. We name these problems directly, early, and often. The conversation isn't "can we deploy this safely?" It's "what human oversight structure do we need so that when - not if - the model gets something wrong, it gets caught before it causes damage?" Less exciting. But honest.
Proof before commitment. We will not design a firm-wide AI implementation plan as a first engagement. I know that's what some clients want. I know it's what some competitors sell. But a six-month, organisation-wide rollout plan built before you've tested a single use case in your actual environment, with your actual data, and your actual people - that's fiction dressed up as strategy. We propose a focused pilot on one specific use case, measure outcomes rigorously over roughly 12 weeks, then make the scaling decision based on evidence. If it doesn't work, you've learned something valuable without disrupting the business. The WHNN® framework we use across all our engagements supports this naturally - I've written about it separately - because it builds in quarterly review points where you reassess priorities based on what's actually happened, not what a slide deck predicted.
Build capability, not dependency. This is where we differ most visibly from the typical consultancy model. When we implement an AI-powered tool - say, an automated proposal generator - your team doesn't just receive a finished system. They sit alongside our engineers throughout the build. They understand how the model was configured, how the quality assurance works, and how to adjust performance when requirements change. When we leave, you're not waiting for a support contract renewal. You're running it yourselves. That's a deliberate choice. It means our engagements have a natural end point. Some consultancies would see that as a commercial problem. I see it as the only way to build trust.
Governance from day one. Not bolted on after deployment. Not a compliance checkbox before go-live. Built into the technical design from the first sprint. Before a single line of code is written, we define with you: who reviews AI recommendations before they're acted on? What's the audit trail? What happens when the model makes a mistake - and who's accountable? In regulated sectors - legal, financial services - this isn't optional, obviously. But even in unregulated environments, governance is what separates a tool people trust from a tool people quietly stop using. If you want to benchmark where your governance maturity sits right now, we've built an AI Readiness scorecard specifically for this purpose.
Measure business outcomes, not AI metrics. An AI implementation might achieve 92% classification accuracy. Lovely. But what does that mean for your firm? Did it reduce the time your team spends on routine intake from six hours a day to four? Did you free up capacity to handle more clients without hiring? Did errors that used to require rework actually decrease? Those are the success criteria we agree before the pilot starts, and they're the metrics we report against. Not inference speed. Not model precision. Business outcomes in business language.
I want to walk through this in enough detail that you can picture each stage. If you've been through a previous AI engagement that disappointed you - and I've written about why that happens more often than it should - you'll be attuned to vague process descriptions. So I'll be specific.
Readiness assessment. Two to three weeks. We review your current state across five dimensions: data quality, systems integration, culture and capability, governance maturity, and skills. The output is a specific readiness profile - not a generic maturity score, but a detailed picture of where your foundations are solid and where the gaps will cause problems if you try to build on them. This is where we sometimes deliver news people don't want to hear. One client - a financial services firm - came in wanting to deploy an AI-powered client communication tool. The technology could do it. But their client data was a mess: different naming conventions across three CRM instances, incomplete contact records, no reliable segmentation. The AI would have been confidently communicating the wrong things to the wrong people. We recommended a data quality programme first. They weren't thrilled. But they'd have been considerably less thrilled six months later when the tool was live and embarrassing them.
Use case identification and prioritisation. Two to three workshops over a week, working alongside your team. We identify three to five specific use cases and rank them by commercial value and implementation feasibility. The critical discipline: we only recommend use cases where the readiness foundations are already in place, or where we've explicitly agreed to fix the foundation gap first. A long wish list of twenty AI applications isn't a strategy. It's a way to avoid making a decision.
Pilot design. For the top-priority use case, we design the pilot with specific success criteria, a realistic timeline (usually 10 to 14 weeks), and - this is important - explicit human oversight requirements built into the technical specification, not described in a separate governance document that nobody reads. You know exactly what success looks like before we start building anything.
Implementation. The build, configuration, and integration work. Your team is embedded throughout - this isn't a handover model. I've seen too many AI implementations where the client team receives a finished system, nods politely, and then quietly stops using it three months later because nobody understood how it worked or what to do when it behaved oddly. Your people are learning as the system takes shape. That's not inefficient. It's the whole point.
Measurement and scaling decision. Fortnightly reporting against the success criteria agreed in the pilot design stage. If something isn't working, we know early. When the pilot concludes, we jointly decide whether to expand. Sometimes the answer is "yes, and here are the next two use cases." Sometimes it's "yes, but we need to strengthen the data layer first." Occasionally it's "this specific use case didn't justify the investment, but here's what we learned that changes how we approach the next one." All of those are good outcomes. The only bad outcome is spending six months and finding out nothing.
From first conversation to an operational, measured AI application: roughly five to six months. Not five to six years. Not a perpetual consulting engagement that never quite reaches the finish line.
In terms of what we need from you: a senior sponsor who can make decisions and unblock access. One or two subject matter experts from the team that owns the process being improved. Access to the relevant data and systems. And honesty - about what's really happening in the workflow, about internal politics that might affect adoption, about previous attempts that didn't work and why. Realistically, two to four hours per week of your senior sponsor's time during the active engagement, and somewhat more from the embedded team members.
I want to share a specific engagement because the details matter more than a polished summary.
A 300-person professional services firm came to us with no AI strategy, no governance framework, and a CTO under pressure from the board to "do something with AI" - a brief that was about as useful as being told to "do something with the internet" in 2004. He was smart and honest enough to say: "I don't know where to start, and I'm worried about committing budget to something that won't deliver."
The readiness assessment took 14 days. We identified over a dozen potential use cases, scored them by impact, feasibility, and risk. Three rose to the top. The first - automated proposal generation - went from pilot to production in a 90-day sprint.
What surprised them: the biggest barrier wasn't technology. Their existing proposal content was scattered across partners' individual drives, with no consistent structure or taxonomy. The AI couldn't automate what wasn't organised. So the first two weeks of the implementation were spent on something decidedly unglamorous - content organisation. Nobody puts that in a case study, but it was the thing that made everything else possible.
What was harder than expected: getting partners to trust the output. Even after the tool was producing proposals that were measurably faster and more consistent, some partners continued doing it manually for weeks. Adoption isn't a technology problem. It's a people problem. We built review workflows that let partners check and approve AI-generated content rather than asking them to trust it blindly. That was the turning point.
The measurable outcome: 60% reduction in proposal turnaround time. Roughly 12 hours of senior consultant time saved per week. The second and third use cases - knowledge management and document summarisation - were commissioned immediately after.
That's what this looks like when it works. Not a revolution. A specific problem, honestly assessed, carefully piloted, and rigorously measured.
Most consultancies list principles that sound responsible but don't actually constrain their behaviour. I want to be more specific than that.
We will not oversell. If the honest answer is "this technology isn't mature enough for your specific context," that's what you'll hear. The engagement I mentioned at the top wasn't a one-off. We've deferred three AI engagements in the past eighteen months because the client's foundations weren't ready.
We will not skip foundations. Even if you want to start building immediately. Even if deferring costs us revenue. If the data quality or governance isn't there, proceeding is irresponsible. We'd rather lose a project today and earn your trust for the right project in six months.
We will not deploy without governance. Every AI application we implement has a governance framework agreed and documented before go-live. No exceptions. In regulated sectors, the client's compliance team reviews and signs off on the governance structure before deployment. This adds time. Clients sometimes find it frustrating. But I've never had a client come back twelve months later and say "I wish we'd spent less time on governance."
We will not leave you dependent on us. The objective of every engagement is to make ourselves unnecessary. Your team should be capable of operating, maintaining, and extending the AI programme independently after we're done. If we've done our job properly, the next use case you implement might not need us at all. And honestly? That's fine. That's the point.
You've probably worked through the rest of what I've written about AI. You understand the readiness requirements. You've seen why pilots fail and what to do differently. You've got a sense of what agentic systems actually look like in a mid-market B2B service firm.
The question now is whether the approach I've described here is the right fit for your firm's specific situation. If you want to find out, book an AI discovery conversation. It takes 45 minutes and ends with a clear view of whether and how we can help. No pitch. No pressure. Just an honest assessment of where you are and what makes sense next.