Capability presale
Selling AI engineers to a client who could already hire them
The client's stated problem was a shortage of AI talent, which is what every staffing pitch claims to solve. I brought a domain proof instead — a loss-detection use case on their own data.
- The operational promise that makes team extension credible
- 48-hour profilesThe operational promise that makes team extension credible
- A loss-detection use case on their data, not a rate card
- Domain proofA loss-detection use case on their data, not a rate card
- Reconciled before the call — the governance catch that mattered
- 1 map, 3 versionsReconciled before the call — the governance catch that mattered
The client
A Series A fuel-retail fintech in the Gulf with its own newly built AI department and an actively hiring chief AI officer — meaning the buyer was a technical leader who would go deep, not a procurement function comparing rates.
The engagement
A capability presale across two scoping calls, backed by a research dossier, a call companion and a client-facing deck, positioned as team extension with a domain proof rather than as staffing.
A working demo of this build exists.
It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.
The problem
Selling engineers into a company that has just built its own AI department and is hiring hard is the hardest version of that sale: the buyer knows exactly what good looks like and can compare you with the person they interviewed yesterday. Rate cards and capability slides do not survive that conversation. Worse, the material we had accumulated contained three different versions of the opportunity map, none of them identical.
What I did
I reframed the offer around proof rather than supply. Team extension gives the operational promises that matter to a hiring leader — profiles fast, people embedded in their team rather than behind an account manager, replacement without a negotiation, and knowledge staying on their side — but none of that differentiates without evidence of domain understanding. So the pitch carried a specific use case in their operational domain where value could be demonstrated on their own data. Then the unglamorous half: three inconsistent versions of the opportunity map existed across the dossier, the analyst deck and the client-facing deck, and I reconciled them before the call, because a technical buyer who spots two different versions of your own story stops listening. I also carried the internal caution into the plan — check whether the client has already built the module we intend to propose, and position accordingly, rather than pitching them their own roadmap.
What was built
Team extension framed as 'your team, extended, not outsourced' — engineer profiles within forty-eight hours, embedding into the client's own team, replacement without argument, knowledge staying with the client — paired with a domain direction where value could be proven on their data, and a market narrative covering regulatory and sector shifts.
On the table at the end
- Research dossier with a market narrative and competitive matrix
- Opportunity map across the client's business lines
- Client-facing deck and a call companion for the presale team
- Question set and commercial framing for the scoping call
What it changed
Differentiated a staff-augmentation offer in the one way that survives a technical buyer: a specific domain use case on the client's own data, backed by a market narrative and an opportunity map — with the internal instruction to check first whether the client had already built the thing we were about to propose.
How it ran
- 01
Read the buyer, not the brief
A technical chief who hires AI people himself will go deep — so the pitch has to survive depth, not breadth.
- 02
Attach a domain proof
A specific loss-detection use case on the client's own data, so team extension arrives with evidence rather than availability.
- 03
Make the operational promises concrete
Profiles within forty-eight hours, embedded working, replacement without argument, knowledge retained by the client.
- 04
Reconcile your own story
Three inconsistent versions of the opportunity map found across artefacts and merged before the meeting.
- 05
Check before you propose
Verify whether the client already has an unreleased version of the module you are about to pitch — and reposition rather than embarrass.
Other work
All case studies →- Corporate banking
Winning back the last call after two meetings had failed
A long-standing account was one bad meeting from closing. I rebuilt the pitch around the client's own operating numbers and a working prototype, and cut every claim we could not source.
- AI infrastructure
Running a live deal like a project, before it was one
A complex infrastructure deal with an unclear decision-maker and a moving scope. I ran it out of the same repository structure we use for delivery — risks, decisions, meetings and all.
- Manufacturing
Three AI pilots aimed at one line of the balance sheet
A building-products manufacturer had capital trapped in inventory and a digital team already delivering wins. I proposed three pilots tied to working capital rather than to a technology roadmap.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.