A partner introduces a prospect. Your sales lead says the account was already in the pipeline. Another partner claims to have shaped the same project. Without a record of what was submitted and what was agreed, the discussion becomes a contest between memories.
A partner deal registration process gives those claims a review path. It records a specific opportunity, the partner's contribution, the decision and any conditions. A small team can start with a form and a controlled register. If you need help designing that workflow, the strategic partnerships work on my services page is a relevant starting point.
1. Decide what registration recognizes
Define the unit being registered before choosing software. An organization, an opportunity and a partner contribution are different things. A customer can have separate projects, and a partner can help an opportunity that someone else originally sourced.
For this original workflow, register a defined opportunity and a claimed contribution. Record whether the request concerns an introduction, sourcing or another contribution your program recognizes. Decide whether those categories follow different rules. Registration is a request for recognition under those rules, not an automatic right to a commission or an exclusive customer relationship.
Read the partnership agreement checklist before turning expectations into a form. Any benefits, exclusions, protection period or commercial obligations need agreement outside this article. Their actual terms are UNKNOWN here.
Hypothetical policy example: a small team accepts requests for a named customer project, reviews evidence of the claimed introduction and issues a written outcome. Existing opportunities trigger review rather than automatic rejection. This example is a process design choice, not a universal partner policy.
2. Copy the minimum deal registration form fields
Keep partner-entered facts separate from reviewer decisions. The form should explain which fields are required and what happens when information is missing. Allow UNKNOWN for facts the partner cannot establish rather than encouraging a guessed project date or unsupported claim.
| Field | What to record |
|---|---|
| Partner identity | [Partner organization, submitting person and reply channel] |
| Customer organization | [Organization name, domain and relevant business unit] |
| Opportunity scope | [Customer need, proposed project and relevant product or service] |
| Contribution claimed | [Introduction, sourcing or other category allowed by the program] |
| Dated evidence | [Activity date, evidence description and restricted evidence reference] |
| Current context | [Known customer discussion, other involvement and next action, or UNKNOWN] |
| Contact information | [Only details needed and permitted for the agreed next step] |
| Internal intake fields | [Request ID, receipt timestamp, reviewer, state and policy version] |
| Internal decision fields | [Outcome, reason, evidence references, decision date and any agreed validity dates] |
Do not require a full email thread when a limited evidence reference will answer the question. Decide who can access supporting material and what can be included in a partner reply. Keep customer details and competing claims out of broadly shared views.
Program requirements differ. For example, Microsoft's co-sell opportunity documentation requires customer consent before contact information is provided to Microsoft for the deal. That is a specific program rule. Your form must reflect your own agreed permissions and data-sharing process rather than copying another program wholesale.
3. Assign states, a reviewer and a reply path
Use one internal register as the decision record. Give each request a stable ID. Assign a primary reviewer and a backup, then record who can approve an ordinary request and who handles exceptions. Keep an acknowledgment separate from an approval.
| State | Meaning and next action |
|---|---|
| Submitted | Request received. Reviewer checks completeness and possible overlap. |
| Needs information | Reviewer names the missing evidence. Submitter supplies it for renewed review. |
| Approved | Decision recorded for the stated scope under the identified policy and conditions. |
| Declined | Reason recorded and communicated. Any reconsideration follows the agreed route. |
| Expired | Agreed validity ended. Any renewal or new request needs a recorded decision. |
| Closed | Registration lifecycle ended, with the reason and underlying opportunity outcome recorded separately. |
Closed does not necessarily mean won. Keep opportunity outcome, registration state and any payment status in separate fields. Likewise, an approved registration does not prove customer qualification, a signed agreement or revenue.
For each state change, capture the actor, timestamp, reason and next action. Send the submitter a status reply limited to information they may see. Agree a review target the team can actually support; this template promises no approval deadline.
4. Check overlap before resolving a partner claim
Match the opportunity
Search the customer name, domain, business unit and project scope. Two records for the same company may concern different opportunities. Normalize obvious naming differences without deleting the original submission.
Compare the evidence
Review existing sales activity, earlier requests and dated partner contributions. A receipt timestamp establishes when a request arrived. Whether that timing determines priority depends on the agreed policy.
Escalate ambiguity
Assign the disputed decision to the named exception owner. Record the rule applied, evidence considered and outcome. Explain the relevant reason separately to each partner without sharing another partner's confidential material.
Hypothetical example: Partner A registers a company-wide project. Partner B later submits a specific departmental project at the same organization. The reviewer asks whether these are one opportunity or two before deciding. If the evidence remains incomplete, keep the request in needs information and name the next action.
A disagreement about recognition should not silently change the customer-facing owner. For collaboration after intake, use the co-selling guide to define how the teams work together on the live deal. Registration resolves the request; it does not supply the whole selling plan.
5. Agree rules of engagement before launch
Copy the following checklist into the program brief and fill in actual decisions. Treat unanswered commercial and permission questions as UNKNOWN. Do not launch with language that different partners can reasonably interpret as conflicting promises.
- Eligibility: which partners, contributions, opportunities and exclusions qualify for review?
- Existing activity: how do open opportunities, earlier introductions and dormant accounts affect a request?
- Decision authority: who reviews, who decides exceptions and how can a partner request reconsideration?
- Visibility: what information may the submitter, sales team and other collaborators see?
- Validity: when does any approved period begin and end, and what does expiry change?
- Renewal: what evidence is required, who requests an extension and who records the decision?
- Closure: what ends registration, what outcome evidence is required and which obligations remain under the agreement?
Set reminders using the actual approved dates. Renewal should preserve the previous decision and show the new basis, not overwrite the original entry. If the agreement does not define a protection period, do not invent one in an acknowledgment email.
Keep a policy version on every decision. Where rules change, explain which version applies to existing requests. Avoid silently applying a new eligibility rule to an older approval.
6. Test the workflow and review friction
Before inviting submissions, walk through a complete request, an incomplete request, a conflicting claim and an expiry. Check what the partner sees, where the reviewer works and how the backup finds the next action. Use fictional records for this exercise.
Include the instructions and an example in partner enablement. A form that exists but is hard to find or impossible to interpret is an adoption problem. Show partners the required evidence and where to ask about a status.
Review pending age, missing-information reasons, conflicts, exceptions and downstream opportunity outcomes. Use the partner scorecard for the broader relationship review. Keep registrations, approvals and actual wins separate so increased submission activity is not mistaken for commercial success.
Add a portal only when the existing process reveals a concrete need, such as access control or status visibility that the current setup cannot handle reliably. Define the decision rules first so any future software has a clear process to support.
A workable deal registration process needs a defined opportunity, useful evidence, a reviewer and a traceable decision. Keep recognition, opportunity progress and commercial entitlements separate, and make conflicting claims an explicit review path.
FAQ
What is partner deal registration?
Partner deal registration is a documented request to recognize a partner contribution to a specific opportunity under agreed rules. Submission records a claim for review. It does not automatically create approval, payment, exclusivity or ownership of the customer.
Can a small team run deal registration without a portal?
Yes. Use a controlled intake form, an internal register, a named reviewer and a separate status reply for each partner. Keep permissions and decision history explicit. A shared spreadsheet containing every partner claim is not a suitable partner-facing status page.
What fields belong on a deal registration form?
Collect the partner identity, customer organization, opportunity scope, contribution, dated supporting evidence and next action. Record an internal submission ID, receipt time, reviewer, state and policy version. Request personal contact details only when needed and permitted.
How should conflicting partner registrations be handled?
Compare the customer, opportunity scope, existing activity and dated contribution evidence against the agreed policy. Escalate an unresolved claim to the named decision owner. Explain the result to each partner without disclosing another partner confidential information.
How long should a deal registration last?
There is no duration assumed in this template. Set any validity period, renewal evidence, reminder process and expiry consequences in the actual program rules. Record the applicable dates on the approved request and preserve its history after expiry.
Need a clearer partner intake process?
Bring the points where submissions stall or ownership becomes disputed. We can discuss a practical registration workflow and the decisions your team needs to agree before implementation.
Book a Call