co-selling with a partner: who owns what in the deal

Co-selling means your people work a specific opportunity next to the partner’s. Every partner wants it, because your engineer in front of its customer makes a small integrator look bigger. It is also expensive: each co-sold deal takes engineer days that cannot go into training the next partner. So ration it with rules partners can see, write down who owns what in each deal, and measure success by how many deals partners close without you.

why proof costs more now

Buyers want to see the product work in their environment before they decide. Forrester argued in 2026 that trials and POCs have become central decision tools, with buying groups averaging 13 stakeholders. In a 2026 G2 survey of 1,038 software buyers, evaluation was the longest stage of buying, about 40% of the process, and IT security review was the most common delay after a vendor was chosen: 39% overall, 50% among enterprise buyers.

Many partners cannot run that kind of evaluation alone on a product they have just added. Somebody has to, and in the first deals that somebody is usually your engineer or your distributor’s.

rules for when to co-sell

Without rules, the partners who shout loudest get your engineers. With published rules, partners accept limits.

Co-sell when at least one of these is true:

1. Size. The expected first-year value is above a threshold you set per product.
2. Activation. It is one of a newly signed partner’s first three deals.
3. Strategic account. A reference candidate, a large public institution, a logo in a target sector.
4. Displacement. It replaces a named competitor your engineer knows well.
5. Complexity. Integration or architecture beyond the partner’s certified skills.

And only if all of these are true:

• the deal is registered,
• the partner has done basic qualification: problem, budget path, timing, decision process,
• the partner’s own engineer attends, so the knowledge stays with the partner.

The registration is the entry ticket to your engineers. That one rule makes deal registration worth something to partners and gives you pipeline visibility at the same time.

three levels of support

Level	For	What the partner gets	Limit
Self-service	Any registered deal	Demo environment, documentation, recorded demos, POC templates	Unlimited
Assisted	Registered and qualified, below the size threshold	One remote session with your engineer, a review of the POC plan	About one engineer day per deal
Full co-sell	Meets one of the five rules above	Workshop at the customer, POC support, architecture, proposal review	Five to ten engineer days per deal

Publish the levels in your partner guide. Partners stop asking for everything once they know what they can get and why.

who owns what

Many conflicts in co-sold deals start with an unspoken assumption about who does what. Write it down once, per deal.

Activity	Partner seller	Partner engineer	Your channel manager	Your engineer
Customer relationship	Owns	Supports	Supports
Discovery and qualification	Owns	Contributes	Coaches	Technical discovery
Demo	Introduces	Delivers or co-delivers	Attends if strategic	Delivers or coaches
POC plan and success criteria	Agrees with the customer	Co-writes	Reviews the commercial side	Co-writes
POC execution	Manages the customer	Executes	Monitors	Supports, escalates
Proposal and pricing	Owns	Bill of materials	Special pricing request	Validates the bill of materials
Negotiation	Owns		Supports
Deployment		Owns		Supports

The partner owns the customer. Your team owns technical depth and escalation. When your channel manager starts negotiating directly with the customer, the partner learns that registering deals with you is a way to lose them.

a POC through a partner needs the same discipline

Every POC, whoever runs it, needs entry criteria before it starts: a qualified opportunity, a budget or funding path, named decision makers, three to seven written success criteria, a fixed end date and a decision meeting already in the calendar. A POC without a decision date is a free evaluation service, and through a partner it is free for two companies.

Practitioner guidance puts guided trials at 15 to 30 days, POCs and proofs of value at 30 to 45 days and pilots at 45 to 90 days. For most mid-market security products, two to four weeks of active testing is enough.

Ignore the vendor claims about POC win rates. No reliable public benchmark exists for POC conversion through partners. A working expectation, and no more than that, is that well-qualified POCs with written criteria convert at roughly half or better, and unqualified ones far less often.

escalation needs three levels

Technical escalation is the main source of engineer overload when nobody defined it. Set three levels, each with a response target: the partner’s engineer first, then your or your distributor’s engineer, then your product support. And draw a clear line between presales help and post-sales support, or your presales team becomes a free helpdesk for every installed customer.

the measure that matters

The goal of co-selling is a partner that no longer needs it. Track one number per partner per quarter: the share of deals it took to close without your engineers. If it rises, your co-selling is building capability. If it stays flat, you are running a free presales service and calling it partnership.

the question for your presales team

How many of your engineer days last quarter went into deals that were never registered?