Key Takeaway
Skip the general partnership talk. Pick one named client problem, fill in a one-page co-delivery blueprint covering who owns the relationship, the build and the run, agree in writing how each firm earns, and ship a single joint proposal within 30 days.
This playbook is for the people who own AI partnerships on the services side: advisory firm partners building an AI practice, agency leaders adding AI work, and alliance managers at platforms trying to get partner-led deployments moving. It covers how two firms get from a first meeting to a first shipped system, using one named client problem as the starting point.
Most AI partnerships between service firms start the same way. Two firms meet, compare capabilities and agree there’s a fit. They sign an NDA (non-disclosure agreement), maybe a partner agreement, put each other’s logo on a slide and plan a joint webinar. Then each side waits for the other to bring a deal.
Months later, the honest answer to “how much revenue has this partnership produced?” is usually zero. Nobody did anything wrong. The partnership was built around the firms, and revenue gets built around clients.
We assume you already believe AI delivery in the mid-market takes more than one firm. If not, start with why delivery is the missing layer in AI ecosystems. The question here is narrower: how do two firms ship something together? Our answer is to skip the general partnership conversation and start with one named client problem.
Why do most AI partnerships between service firms produce no revenue?
Because they start from capabilities instead of a client, so nobody owns the first deal, the hard questions get deferred and incentives stay vague. None of that has anything to do with the quality of either firm.
Nobody owns the first deal. Each side assumes the other will surface an opportunity. Partner managers juggle dozens of relationships, and the ones without a live account drift.
The hard questions get deferred. Who leads the client conversation? Whose paper does the contract go on? Who supports the system at 2 a.m.? These feel awkward to discuss in the abstract, so they get pushed to “when we have a deal.” When the deal shows up, there’s no time to settle them cleanly and the client sees the seams.
Incentives stay vague. If a firm doesn’t know how it makes money on a joint deal, it won’t bring one. Ambiguity about margin kills partner motivation faster than anything else.
Starting from a named account forces every one of these questions into the first meeting, where they’re cheap to answer.
What is the one-account rule?
Before any partnership paperwork beyond an NDA, the two firms pick one specific account and plan it together as if it were already a deal. If there’s no named account, a tightly defined vertical problem or a marketplace gap will do.
There are three valid starting points, in order of preference:
- A named client with a stated need. “Our client, a regional distributor, wants to cut the time it takes to process supplier invoices.” Best case. Real problem, real buyer, real timeline.
- A vertical thesis. “Half our manufacturing clients are asking about quoting automation.” Good, but you’ll still need to pick one client in that vertical to make the blueprint concrete.
- A marketplace gap. For platform alliance teams: “Customers on our marketplace keep asking for an integration or agent no partner offers.” This works when the platform can point to real demand signals.
If neither side can bring any of the three, the partnership isn’t ready. Better to find that out early.
What goes into a co-delivery blueprint?
Ten fields on one page, filled in for the chosen account. It’s the core artifact of this playbook and what we work through with prospective partners in a first session.
| Field | What to write | Why it matters |
|---|---|---|
| Account and problem | Client name, the problem in their words, why now | Anchors everything in a real buyer |
| Business owner at the client | The person accountable for the outcome | No owner, no project |
| Relationship owner | Which firm leads the client relationship, and which person | The client should always have one primary contact |
| Scope owner | Who defines and signs off on what gets built | Stops the partner and the builder from promising different things |
| Build owner | Who designs, engineers, tests and deploys | Clear accountability for the system working |
| Run owner | Who monitors, upgrades and handles incidents after go-live | The most skipped field and the most important one for renewal |
| Contract structure | Whose paper, and how the other firm is engaged | Decides liability, invoicing and procurement path |
| Value exchange | How each firm earns on this account, in writing | Keeps both sides motivated past the first deal |
| First activation | The first thing that ships, and the date | Turns a plan into a deliverable |
| Success metric | The number the client will judge the project on | Lets both firms tell the same success story |
A blueprint with every field filled in is a joint account plan. One with gaps tells you exactly which conversation to have next.
Who should own what in an AI co-delivery partnership?
The firm with the client’s trust keeps the relationship. The firm with the engineering keeps accountability for the system working. Ownership is shared only at scope, because that’s where mismatched promises do the most damage.
Here’s the default split we recommend when an advisory firm or agency works with a delivery partner. Adjust it per account, but start from something explicit.
| Activity | Relationship partner (advisor or agency) | Delivery partner |
|---|---|---|
| Client relationship and executive sponsor contact | Owns | Supports |
| Problem framing and business case | Owns | Contributes technical feasibility |
| Scope and acceptance criteria | Co-owns | Co-owns |
| Architecture and technical design | Reviews | Owns |
| Build, integration, testing | Informed | Owns |
| Change management and user adoption | Owns | Supports with training material |
| Production monitoring and incidents | Informed | Owns |
| Renewal and expansion conversation | Owns | Brings usage data and roadmap input |
For what owning build and run means on the technical side, see AI agent architecture: what production systems actually look like.
How should partner firms split revenue on a joint AI deal?
Pick one of four models per account and put it in writing before the first client meeting: subcontract, co-prime, referral or marketplace listing. None is right every time. What matters is that partners know how they’ll make money before they bring a client.
| Model | How it works | Works best when | Watch out for |
|---|---|---|---|
| Subcontract | Relationship partner holds the contract and engages the delivery partner under it | Partner has the master agreement and wants one invoice to the client | The delivery partner’s run obligations need to be mirrored in the subcontract |
| Co-prime | Both firms contract directly with the client for their own scope | Large engagements where the client wants direct accountability from each | Needs a clear interface between the two scopes |
| Referral | Partner introduces, delivery partner contracts directly, partner earns a referral fee | Partner doesn’t want delivery liability or ongoing involvement | Partner loses visibility. Works poorly for advisory firms that want the ongoing relationship |
| Marketplace listing | Delivery partner’s offer is listed or sold through a platform marketplace | Platform has buyer demand and a way to transact | Platform terms and fees vary. Confirm before pricing |
Specific percentages and fees belong in a commercial conversation, not a blog post. If one firm keeps saying “we’ll sort out the economics later,” treat that as a preview of how the partnership will go.
Where do co-sold AI projects usually break down?
At the handoffs between firms, and mostly at two of them: the proposal and the run phase. Every co-sold project passes through five handoffs, and each is a place where the client can feel the seam.
- Introduction. The relationship partner introduces the delivery partner. Agree in advance on positioning (“our engineering team for this work” versus “a firm we recommend”) and keep it consistent.
- Discovery. Both firms in the room. The relationship partner frames the business problem and the delivery partner asks the technical questions about data, systems and access. One combined set of notes goes back to the client.
- Proposal. One document, one price, one timeline. Never two proposals the client has to reconcile.
- Build to production. Weekly status goes to the client through the relationship owner, with the delivery lead present. Scope changes go through the scope owners on both sides.
- Run and renewal. Monthly reporting on usage, quality and incidents, tied to the success metric from the blueprint. The relationship partner leads the renewal conversation with that data.
When two firms write separate proposal sections, their assumptions don’t match. And if nobody planned the run phase, the renewal conversation opens with “it used to work better.”
How do two firms get to a first activation in 30 days?
Run four weekly steps on one account: a blueprint session, commercials, joint discovery and a single proposal. A partnership gets real when the first joint thing ships, and this gets two firms from first meeting to first client-visible output in a month.
Week 1: Blueprint session. 45 to 60 minutes. Fill in the co-delivery blueprint for one account and spot the gaps.
Week 2: Commercials and positioning. Agree on the value exchange model and how the delivery partner gets introduced. Settle whose paper the contract sits on.
Week 3: Joint discovery. Both firms meet the client together. Confirm the problem, the owner and the data access needed.
Week 4: Single proposal. One proposal, one price, one first milestone, with run ownership named explicitly.
Not every account converts. A blueprint that stalls in week 2 because the economics don’t work is still a useful result. Now both firms know.
What does a co-delivery blueprint look like in practice?
Here’s an illustrative example, not a real engagement. An advisory firm with a strong logistics practice notices several clients fighting the same problem. Customs and freight documents get checked by hand, errors cause delays, and the people who know the rules are hard to hire.
The firm’s practice lead and a delivery partner run the blueprint for one client, a mid-sized freight forwarder.
- Account and problem: a document review backlog at the forwarder, with errors causing shipment holds
- Business owner: VP Operations
- Relationship owner: the advisory firm’s engagement partner
- Scope owner: joint, with the advisory firm’s process specialist and the delivery lead
- Build and run owner: the delivery partner
- Contract structure: subcontract under the advisory firm’s existing agreement
- First activation: an assistant that pre-checks one document type and flags likely errors for a human reviewer, live for one team in eight weeks
- Success metric: error rate and review time per shipment, against a baseline from the month before launch
The value showed up before any code. Filling in the run owner field revealed that the advisory firm assumed the client’s IT team would support the system, and the client assumed the advisory firm would. Sorting that out in week 1 took one conversation. Finding out after launch would have cost the relationship.
Once the first account works, the vertical thesis has proof behind it, and the next blueprint for a similar client goes much faster. To frame the client-side numbers, see how to build the business case for AI investment.
How do you know an AI partnership is ready to scale?
After one or two accounts, you’ll know whether to formalize. Look for these signs:
- At least one blueprint turned into a signed engagement
- Both firms describe the ownership split the same way without checking notes
- The value exchange held up without renegotiation mid-project
- The client experienced one team, not two vendors
- There’s a repeatable pattern (same vertical, same problem shape) worth packaging
If those hold, a formal partner agreement and joint go-to-market make sense. If they don’t, more paperwork won’t help.
Frequently Asked Questions
What is a co-sell partnership in AI services?
It’s two firms selling and delivering one AI project together, usually an advisory firm or agency that holds the client relationship and a delivery partner that builds and runs the system. It works when ownership, contract structure and how each firm earns are agreed per account before the client meeting.
Should an AI partnership start with a partner agreement or a client?
Start with a client. Sign an NDA, then plan one named account together as if it were a deal. The formal partner agreement comes after one or two accounts prove the pattern.
Who should support an AI system after go-live in a partner deal?
Name a run owner in writing before the proposal goes out. In most splits it’s the delivery partner, since they built the system and own monitoring and incidents. Leaving it vague is the most common way joint AI projects lose the renewal.
What client problem would you bring to a blueprint session?
If you lead alliances at a platform, run an advisory practice or own an agency’s AI offer, bring one client challenge, a vertical thesis or a gap in a marketplace you work with. We’ll fill in a co-delivery blueprint with you covering ownership, value exchange and the first activation. The blueprint is yours to keep, even if we never work together. Book a blueprint session.