AI consulting services that end in a build plan.
Our AI consulting services exist to answer three questions in weeks rather than quarters: which of your candidate use cases are worth building, what each would actually cost to run, and which should be killed now. The deliverable is a costed plan specific enough to hand to any supplier — including one that is not us.
There is a specific failure this engagement is designed to prevent. A company runs a dozen AI pilots, several work well enough in a demo, none reach production, and eighteen months later the honest answer to "what did we get" is a set of prototypes and a subscription bill. It happens because feasibility was assessed on whether the model could do the task, not on whether the surrounding system could be run, measured, staffed and paid for.
So we assess four things per use case, and a candidate has to pass all four: value (a number someone owns), data (does what the model needs actually exist, and is it clean enough), operability (who runs this at 2am, and how would they know it broke), and unit cost (per interaction, at your real volume, with a model you can afford). Most shortlists lose half their entries at the data question, and finding that out in week two is the point.
We are an engineering firm, not a strategy house, and that shapes the advice. Every recommendation is costed by people who would have to build it, which makes the estimates less flattering and more useful. It also means we will tell you when the answer is not AI — better search, a fixed workflow, or fixing the product data first is a common conclusion and an honest one.
DTN has built and operated commerce systems since 2005 across 200+ projects and four continents, which is the experience the operability question actually draws on. A recommendation that ignores who maintains the thing is not a recommendation.
What an assessment covers.
Use-case discovery and ranking
Workshops with the people who do the work, not just the people who sponsor it. Candidates scored on value, data readiness, operability and unit cost, and ranked on the composite.
Data readiness review
Whether the records a model would need exist, where they live, how clean they are and what it would take to make them usable. The most common reason a promising use case dies.
Unit economics
Cost per interaction at your real volume, across model options, including caching and routing strategies. The number that decides whether a feature survives its first month of success.
Build-versus-buy
An honest read on where an off-the-shelf product beats custom work. Sometimes the recommendation is to buy a tool and integrate it, which is a smaller invoice for us and the right answer.
Risk, privacy and vendor exposure
Data residency, retention, PII handling, what happens to your prompts, and how much lock-in each architecture creates. Documented as decisions rather than assumed.
A costed roadmap
Sequenced with effort, dependencies and owners against each item — written so another supplier could execute it, because that is the test of whether it is real.
How the assessment runs.
Week one — inventory
Interviews with the teams doing the work, a look at the systems and data, and a long list of candidates. No filtering yet.
Week two — feasibility
Data reality-check and unit-cost modelling against the long list. This is where most candidates fail, and where the engagement earns its fee.
Week three — plan
The survivors sequenced into a costed roadmap, with the reasoning for every rejection written down so the decision does not get relitigated quarterly.
Handover and decision
Presented to the people who have to fund and run it. If you take it to another supplier, it is specific enough to price. That is deliberate.
What exists at the end that did not exist before.
A rejection list is a deliverable, not a failure. Knowing which four of your six ideas will not pay, and precisely why, is usually worth more than a plan for the two that will.
The stack.
Common questions.
How is this different from a strategy consultancy's AI practice?
We would build it. Every estimate in the roadmap comes from people who would be accountable for delivering it, which tends to make the numbers larger and the plan more likely to survive. What we do not offer is organisational change management at enterprise scale — if that is the actual need, a strategy house is the right supplier and we will say so.
Will you recommend building with you?
Sometimes, and we will flag the conflict where it exists. The roadmap is deliberately written to be executable by anyone, and the assessment is priced as its own engagement rather than as a loss-leader we need to recoup on a build. If the honest recommendation is an off-the-shelf tool or your own team, that is what the document says.
What if we already know the use case?
Then skip most of this and go straight to a scoped build — automation, agents or integration, depending on shape. A shorter version of the assessment covering just data readiness and unit cost is still worth doing, because those are the two things that kill projects after the decision is made.
Do you cover AI governance and compliance?
To the extent it drives architecture — data residency, retention, PII handling, model-provider terms, audit trails and what each choice locks you into. We document those as engineering decisions. We are not a law firm and do not give regulatory opinions; where you need one, the plan says where.
Who should be in the room?
The people who do the work, someone who owns the number you want to move, and someone who will have to operate the result. Assessments that only involve sponsors produce use cases that sound good and cannot be staffed.
Where an assessment usually leads.
Bring your shortlist. We will tell you what survives.
Send the use cases you are weighing and roughly what data you hold. The first call is enough to tell you which ones have an obvious data problem — no charge for that part.