Key takeaways: Organization vs individual referral attribution is a business-policy choice about who was acquired. Credit a person when the person is the customer; credit the buying organization when several people act for one account. Keep the referring actor and reward beneficiary separate. The four worked scenarios below define intended credit, ownership and exclusions before any field mapping. They are illustrative policies, not claims about automatic Cello enforcement.
Last updated: 12 November 2026.
- What is organization vs individual referral attribution?
- Which four identities must a credit policy separate?
- How do you choose the buying unit?
- How should a new-company referral receive credit?
- What if finance pays after a different person signs up?
- What if two employees refer the same new company?
- Does a teammate joining an existing workspace qualify?
- Which exceptions need a named owner?
- What should implementation acceptance tests prove?
- Frequently asked questions
What is organization vs individual referral attribution?
Individual attribution treats a person as the acquired customer. Organization attribution treats a business account as the acquired customer even when different employees discover, evaluate and pay for the product. Choose the unit that matches the commercial relationship, then specify whether the program rewards new logos, expansion or another event.
This decision comes before implementation. It does not choose a cookie window, compare first-touch with last-touch, or specify an API field. A sole professional buying a personal subscription can fit individual attribution. A shared business workspace billed under one contract usually calls for an organization-level policy, with explicit exceptions.
Which four identities must a credit policy separate?
Separate the referring actor, referred individual, buying organization and reward beneficiary. These roles answer different questions: who introduced the buyer, who used the product first, which entity bought it, and who is permitted to receive the reward. A single email address is not a safe substitute for all four identities.
The referring actor can be a consultant who never becomes a user of the referred account. The referred individual can be a team lead whose finance colleague later pays. The buying organization can own several workspaces. The reward beneficiary must satisfy your terms and relevant employer or gift restrictions; the introducer is not automatically entitled to personal payment.
How do you choose the buying unit?
Choose an individual unit for genuinely independent personal purchases and an organization unit for a shared business purchase. Decide separately how expansions, subsidiaries and repeat purchases qualify. The matrix below is a policy starting point, not a universal rule or a statement that every exception is automatically configurable in Cello.
Situation | Proposed unit and credit | Non-qualifying outcome |
|---|---|---|
Independent personal purchase | Individual buyer, subject to written eligibility | Another login by the same customer |
New shared business account | One buying organization | Each employee counted as a new logo |
Separate signup and payer | Same verified buying account | Second reward just for a new payer email |
Additional workspace or seats | Expansion only if separately eligible | Relabeling existing-account growth as new logo |
Consultant introducing several clients | Separate verified client organizations | Treating the agency email domain as the acquired entity |
How should a new-company referral receive credit?
Under the illustrative new-logo policy, credit one eligible external referrer for acquiring a genuinely new buying organization after its qualifying payment. Record the introduced individual as a contact, not a second customer. RevOps owns the new-versus-existing decision; finance owns payment confirmation and reward approval under the agreed terms.
Scenario 1: Consultant Maya introduces product lead Leo at Northbridge Ltd. Leo opens a new workspace, and Northbridge becomes the contracting customer. Referring actor: Maya. Referred individual: Leo. Referred entity: Northbridge. Account status: new. Intended credit: one new-logo referral to Maya, subject to beneficiary eligibility and the stated payment condition.
Non-qualifying outcome: If Northbridge already has an active customer account, do not count Leo’s new workspace as another new logo. Route a possible expansion to its separate policy. Retain the existing-account check and introduction record rather than silently overwriting the original acquisition source.
What if finance pays after a different person signs up?
A change of payer should not create a new acquired customer when both people act for the same buying organization. Preserve the approved referral relationship to that account and verify the later payment belongs to it. The policy owner should resolve the association before finance approves a reward, not infer it from matching names.
Scenario 2: Customer advocate Ana introduces operations lead Ben at Larch Systems. Ben signs up; finance manager Priya pays the invoice later. Referring actor: Ana. Referred individuals: Ben as signup contact and Priya as payer. Referred entity: Larch Systems. Account status: new. Intended credit: one qualified company acquisition to Ana when the agreed payment condition is met.
Owner: RevOps confirms the product-to-CRM-to-billing association, with engineering implementing it and finance confirming collection. Non-qualifying outcome: An unpaid invoice or a payment belonging to an unrelated account does not qualify. Do not award a second referral to Priya merely because her email appears on the transaction.
The affiliate-link guide covers the adjacent signup/payer association. Here, the policy decision is that one organization, not each contact, is the acquired unit.
What if two employees refer the same new company?
Two introductions to the same organization should be evaluated as competing claims for one acquisition under a new-logo policy. Set a priority rule before rewards are approved and retain evidence for the resolution. Neither the number of signup contacts nor the number of workspaces determines how many new organizations were acquired.
Scenario 3: Referrers Owen and Sara independently introduce employees Nina and Alex at Cedar Analytics. Nina and Alex join one new company account. Referring actors: Owen and Sara. Referred individuals: Nina and Alex. Referred entity: Cedar Analytics. Account status: new. For this example only, the written policy awards the first documented eligible introduction, provided no existing sales-opportunity exclusion applies.
Intended credit: If Owen’s eligible introduction was first, Owen receives the one acquisition credit. RevOps adjudicates against timestamps and evidence, with finance holding approval until resolution. Non-qualifying outcome: Sara’s later introduction does not earn a second new-logo reward. A split reward requires an explicitly different policy, not an ad hoc interpretation after payout.
Does a teammate joining an existing workspace qualify?
A teammate joining an existing workspace is collaboration, not a newly acquired business under a new-logo policy. Preserve the invite as a product event and exclude it from acquisition rewards. If your business separately incentivizes seats or expansion, define that program’s eligibility and economics without relabeling collaboration as a new customer.
Scenario 4: Existing customer Alder Studio’s employee Sam invites colleague Jo. Referring actor: Sam as inviter. Referred individual: Jo. Referred entity: Alder Studio. Account status: existing. Intended new-logo credit: none, even if Jo has never logged in before. Growth owns the acquisition exclusion; product owns the teammate-invite experience; RevOps keeps the reporting categories separate.
Non-qualifying outcome: Jo’s new user record does not earn a new-company reward. If Alder later buys more seats, assess the transaction under the separate expansion policy. Do not retroactively change the original acquisition event or assume the inviter becomes the rewarded referrer.
Which exceptions need a named owner?
Exceptions need an accountable business owner and an evidence record, not just more identity fields. Specify how shared parents, agencies, account merges and multiple workspaces affect eligibility. Treat email-domain matching as a review signal, not proof that two records represent the same company or that different domains represent independent buyers.
RevOps should record the contracting entity and internal customer identifier, relevant parent relationship, known existing opportunities, competing claims and reason for the final decision. Finance confirms the payable beneficiary and collection; engineering preserves the chosen identity across systems. An agency domain serving several clients needs explicit client-account mapping, not a blanket agency-level match.
Use stable internal IDs and retain an auditable mapping when accounts merge. Specify whether subsidiaries count independently and whether eligibility is assessed at introduction or conversion. Document corrections prospectively and retain previous credit decisions; a CRM merge should not silently create another reward.
What should implementation acceptance tests prove?
Implementation tests should reproduce the written policy across signup, CRM and billing records before launch. Test the four scenarios, then add a shared parent, an agency-managed account, a merge and a refund. Inspect expected credit and explicit non-qualifying outcomes, rather than accepting a successful event delivery as proof of correct attribution.
Cello’s signup and purchase documentation describe organization-level attribution. Interface-specific identifiers and examples need engineering validation against the integration you actually use. This article intentionally provides no universal payload recipe, automatic arbitration claim or domain-based identity guarantee.
Hand the approved policy to engineering with the expected account, referrer, beneficiary, eligibility reason and finance evidence for each scenario. Use the non-Stripe implementation guide for connector work and the tracking guide for background methods. If you are evaluating both customer and partner programs, the platform pilot guide covers system acceptance, not the policy choice itself.
Frequently asked questions
Is the referring actor the same as the referred customer?
No. The referring actor makes the introduction; the referred customer is the person or organization acquired. Keep both identities and the eligible reward beneficiary explicit.
Should all B2B SaaS use organization attribution?
No. Match the unit to the commercial relationship. Independent individual subscriptions and shared organization contracts need different policies. Write down exceptions rather than choosing solely because the product is B2B.
Does a new employee mean a new customer?
Not under a new-logo organization policy. A new user in an existing customer workspace is collaboration or possibly expansion under separate terms, not another acquired company.
Can an email domain prove account identity?
No. Agencies, shared domains, subsidiaries and multiple domains make that inference unsafe. Use an authoritative customer record and treat domains as supporting review signals.
What happens when signup and payment contacts differ?
Associate both contacts with the verified buying account. If the policy rewards that organization’s qualifying payment, the payer change does not create a second acquired customer or transfer credit by itself.
Who resolves competing referral claims?
Name a policy owner, usually RevOps with the program lead. Apply a written priority rule, retain the introduction evidence and hold reward approval until the claim is resolved.
Do these scenarios describe automatic Cello rules?
No. They are worked policy examples. Validate configuration, custom integration and manual-review responsibilities separately before assuming software enforces each outcome.
What should engineering receive before implementation?
Provide the chosen buying unit, stable account mapping, beneficiary rules and test cases with expected credit and exclusions. Engineering then validates the fields for the specific integration, rather than deriving policy from a sample payload.
