Attribution Rules That Stop Channel Conflict

Deal registration conflict rules are the published policy that decides who gets credit when more than one party claims the same opportunity — a partner and your direct team, or two partners. They only work if they were written before the conflict, and if every term in them can be evaluated from a record.

Channel conflict almost never starts as a conflict. It starts as an ambiguity nobody noticed: an account a partner has been working for months that your AE also has in their territory, or two resellers who both introduced you to different people at the same company.

It becomes a conflict at the moment somebody has to decide, and by then both parties have already invested. Whatever you decide, one of them learns something about how your program works — and if the rule appears to have been invented at that moment, both of them learn it.

The fix is boring and it works: write the rules down, publish them, and make every term evaluable from a record you hold. Below is the set that covers the cases that actually happen, and the edge case each one still misses.

What are deal registration conflict rules?

They are the tie-breakers in your partner program: who has a claim, how long it lasts, what beats what, and what can take it away.

A registration is a claim on an opportunity. A conflict rule is what happens when two claims overlap, or when a claim collides with your own direct pipeline. Without published rules, every collision is resolved by negotiation, and negotiation rewards whoever escalates hardest rather than whoever did the work.

Six rules cover almost everything. The interesting part of each is what it fails to cover.

Rule 1: eligibility — what can be registered at all

State the floor: minimum deal value, acceptable stages, required fields, and whether existing customers can be registered.

Microsoft’s own program is a useful model here, because its criteria are unusually explicit. An Azure IP co-sell deal is eligible for registration only when the status is won, an eligible solution is in the deal, the deal type is partner-led or co-sell, the value is at least USD 25,000, and the customer account is Microsoft-managed. No judgement, no conversation — six conditions that either hold or don’t.

The edge case it misses: the deal that grows. A partner registers a small opportunity below your floor, works it for four months, and it lands at ten times the size. If eligibility is evaluated only at submission, they were never protected. If it is evaluated only at close, your floor does nothing. Say which, in writing.

Rule 2: what beats what — first to register, or first to qualify

First to register is simple, auditable, and rewards speed. First to qualify — requiring evidence of a real, engaged opportunity — rewards work, and requires someone to judge the evidence.

Most programs should choose first-to-register with a qualification bar: the registration is accepted on submission, but only if it carries the fields that demonstrate engagement. Suger’s registration form encodes exactly that shape, requiring a partner brief of at least twenty characters alongside the opportunity, customer, close date, and deal value — a small requirement that eliminates speculative bulk registration without introducing a subjective review.

The edge case it misses: the partner who registers an account before doing anything, purely to block others. The counter is not a stricter bar at submission; it is Rule 4.

Rule 3: the protection window — how long a claim lasts

A registration should grant exclusivity for a fixed period, stated in days, starting at approval.

Pick a length that matches your actual sales cycle. Too short and partners disengage before they are protected; too long and one partner can park an account for a year.

The edge case it misses: the deal that is genuinely progressing when the window ends. Publish an extension mechanism — requested before expiry, granted on evidence of progress — or the rule will be broken ad hoc, which is the same as not having it.

Rule 4: expiry — the rule most programs forget

Every registration needs an end date, and it needs to be enforced automatically.

This is the single most common structural failure in partner programs. A registration with no expiry converts a claim into a permanent reservation, and after two years your best accounts are all “taken” by partners who are not working them. The partner bringing a real, funded opportunity is then told the account is unavailable, and takes that opportunity elsewhere.

Expiry also solves Rule 2’s blocking problem without needing anyone to judge intent.

The edge case it misses: the honest partner whose deal slipped for reasons outside their control. A short grace period plus a documented extension path handles it, and both should be published.

Rule 5: house accounts and named exclusions

Some accounts are not available for registration: existing customers in a renewal window, strategic accounts your direct team owns, accounts under an active enterprise negotiation.

Publish the categories before anyone registers against them. You do not have to publish the list — most companies can’t — but a partner who discovers the concept of a house account only when their registration is rejected has learned that the program has hidden rules.

The edge case it misses: the account that becomes a house account after a partner registered it. Registrations already accepted should be honoured to the end of their window. Retroactive exclusion is the fastest way to lose partners who were doing exactly what you asked.

Rule 6: clawback — when credit is reversed

Commission that has been paid sometimes has to come back: the customer cancels, refunds, never pays, or the deal is found to have been registered improperly.

Suger’s deal registration carries a clawback window in days alongside the commission rules — rate, maximum cap, minimum deal value, renewal commission — and a payment trigger, so the reversal condition is part of the same record as the payment. That is the right place for it. A clawback policy that sits in a PDF and not on the deal is a clawback policy you will not enforce consistently.

Note that the underlying risk is real and not theoretical: Microsoft’s own marketplace payouts can be recovered from publishers if a customer never pays, with unpaid amounts subtracted from future payouts. Your channel program is exposed to the same thing one layer down.

The edge case it misses: partial delivery. A deal that shrinks at renewal rather than cancelling outright needs a proportional rule, not a binary one.

The rules in one table

Rule	Decides	Evaluated from	Still misses
Eligibility	What can be registered	Deal value, stage, required fields	Deals that grow past the floor after submission
Priority	Who wins a collision	Submission timestamp plus a qualification bar	Blocking registrations with no intent to work
Protection window	How long exclusivity lasts	Approval date plus a fixed term	Genuine deals that slip past the window
Expiry	When a claim dies	The same clock, enforced automatically	Slippage outside the partner’s control
House accounts	What is off-limits	An account flag set before registration	Accounts that become strategic later
Clawback	When credit is reversed	Payment trigger plus a clawback window	Deals that shrink rather than cancel

Every entry in the third column is a field, not an opinion. That is the test: if a rule cannot be evaluated from a record you already hold, it is not a rule, it is a preference — and preferences get relitigated every quarter.

Publish the policy, not just the tiers

Two things separate programs that get this right.

The rules are published to partners. All six, in plain language, with the numbers filled in. Partners plan around what they can predict. A protection window they know about changes their behaviour; one they discover on rejection changes their opinion of you.

Direct sales is bound by them too. The rule that keeps a program credible is the one that says what happens when your own AE walks into a registered account. If the answer is “the partner is protected,” say so and pay it. If it is not, do not run a registration program, because your partners will find out and the discovery is worse than the policy.

Underneath both sits an accounting question — what a partner actually earned credit for — which is a separate decision from who has the claim. Partner-sourced vs partner-influenced revenue covers that split, and deal registration software for ISVs covers the lifecycle the rules operate on.

Where marketplace deals complicate it

One wrinkle specific to cloud go-to-market: a partner-registered deal often has to transact through a cloud marketplace, as a channel partner private offer or a multiparty private offer. That introduces a third party — the cloud — with its own attribution model and its own registration rules, which do not know about yours.

Two consequences worth writing into your policy:

Your registration and the cloud’s registration are different records with different criteria and different clocks. Microsoft’s 72-hour gap between creating a deal and marking it won, for example, is a constraint on the cloud’s record, not yours. How co-sell works covers those gates.
Credit can diverge. A deal can be partner-sourced in your program and partner-led in the cloud’s, or vice versa. Decide which one your commission plan pays on, and say so.

Frequently asked questions

What are deal registration conflict rules? The published policy deciding who gets credit when two parties claim the same opportunity: what can be registered, who wins a collision, how long protection lasts, when it expires, which accounts are excluded, and when credit is reversed.

How long should a deal registration protect a partner? Long enough to cover a typical sales cycle, stated in days and enforced automatically. Publish an extension path for deals that are genuinely progressing when the window ends.

Should registrations expire? Yes, always. A registration with no expiry becomes a permanent reservation, and after a year or two your best accounts are claimed by partners who are not working them.

First to register or first to qualify? First to register, with a qualification bar built into the form. It stays auditable and rewards speed, while required fields — a real close date, a deal value, a written brief — screen out speculative claims.

What is a clawback window? A defined period after payment during which commission can be reversed if the deal cancels, refunds, or is found to have been registered improperly. It belongs on the deal record, not only in a policy document.

Does the cloud provider’s deal registration replace mine? No. They are separate records with separate criteria and separate clocks. A deal can be credited differently in each, so your commission plan has to state which one it pays on.

Takeaways

Channel conflict is an unwritten rule discovered late. Publish the six rules — eligibility, priority, protection window, expiry, exclusions, clawback — before you need them.
If a rule cannot be evaluated from a record you hold, it is a preference, and preferences get relitigated.
Expiry is the rule most often missing and the most damaging to omit: without it, claims become permanent reservations.
Say what happens when your own direct team walks into a registered account. That answer is the program’s credibility.
Put the clawback window on the deal record beside the commission terms, not in a policy PDF.
Your registration and the cloud’s are different records with different clocks. State which one commission pays on.

Rules only hold if the system enforces them. See how deal registration in Suger carries the protection terms, commission rules, and clawback window on the deal itself — so a conflict is resolved by the record instead of by whoever escalates first.