Deal governance
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.
- Tracked before a contract existed, not after
- 17 risksTracked before a contract existed, not after
- Recorded and indexed, so the account has one memory
- 15 meetingsRecorded and indexed, so the account has one memory
- Numbered decisions with owners, from presale onward
- Decision logNumbered decisions with owners, from presale onward
The client
A US edge-AI infrastructure startup building distributed capacity across many points of presence, with a large founding leadership team, a general-availability target under a year away, and a vendor decision still open.
The engagement
A presale run as a governed engagement: scope, risk register, decision log, meeting records, statement of work and a portfolio dashboard, all maintained from before the contract existed.
The problem
Complex deals are usually run out of a chat thread and one person's head. The scope moves between calls, nobody can say when a position changed, and the identity of the real decision-maker is a matter of opinion — which becomes an expensive problem when the deal converts and delivery inherits a scope nobody can reconstruct.
What I did
I ran the presale on the same structure we use for delivery, which sounds heavy and is not: scope in one place, a risk register maintained from the first call, a numbered decision log so a change of position has a date and an owner, and an indexed record of every meeting. That does three things at once — it makes the account's memory independent of any individual, it lets sales, presale and delivery hand the deal between them without a briefing, and it means that if the deal converts, delivery starts from a real baseline rather than from a proposal and a hope. Where the decision-maker was genuinely unknown, that was recorded as an open question with candidate hypotheses rather than quietly assumed, because an unnamed approver is a risk with a name.
What was built
The delivery operating model applied to a presale: a repository holding scope, risks, decisions, meeting records and the draft statement of work, plus a dashboard, so the deal could be handed between sales, presale and delivery without a briefing call.
On the table at the end
- Deal repository: scope, seventeen risks, numbered decision log, fifteen meeting records
- Draft statement of work
- Portfolio-style dashboard for the deal
What it changed
Gave a deal with an unnamed decision-maker and a shifting scope the same traceability as a live project — seventeen tracked risks, a numbered decision log and fifteen recorded meetings — so the negotiation ran on a record rather than on recollection.
How it ran
- 01
Open the register before the contract
Risks tracked from the first call, when they are still cheap — seventeen of them by the time the decision was pending.
- 02
Number the decisions
Every position change dated and attributed, so the negotiation runs on a record rather than on competing recollections.
- 03
Index the meetings
Fifteen records held centrally, making the account's memory independent of whoever attended.
- 04
Record the unknown approver
The unidentified decision-maker logged as an open question with hypotheses, not assumed into the plan.
- 05
Hand over without a call
Sales, presale and delivery working from one repository, so conversion does not require reconstruction.
Other work
All case studies →- Professional services
A project office that lives in a git repository
Project knowledge lived in people's heads and chat threads, and AI tools were producing confident documents with no provenance. I made the repository the single source of truth and gave every project management role a written protocol.
- Fuel retail fintech
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.
- Enterprise software
Inheriting six live client engagements in one week
A departing manager, six active accounts, and clients who found out by email. I built a handover pack per engagement and a generic pack per engagement type, so the next handover would not depend on me either.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.