Partners send leads by email and ask three months later what happened to them. Here is the model behind a tracker that answers that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A partner referral tracker is four parts: registration that establishes who found the deal and when, deduplication against your existing pipeline, a protection window with clear expiry rules, and a payout tied to a closed outcome. The conflict a tracker has to resolve is the one where a partner registers an account your team was already working. Decide that rule before you build, because it is the only part partners will remember.
Partner referrals
5
Waiting on review
68%
Acceptance rate
7
Lapsing in 14 days
94,200
Owed, not yet paid
Vantor, Bright Partners
domain matches an open deal
Halden Foods, Cordell
protected until 1 Dec
Kestrel Ltd, Meridian
protected until 1 Nov
Fenwick, Cordell
expires in 6 days
Northrise, Cordell
won · 240K · payable
You run partnerships or the revenue operations behind them. You already know your partner tiers and your referral terms. What you want is for registrations to be decided in a day, and for partners to stop emailing to ask about deal status.
What a partner does, what you do, and where the two meet.
Account, contact, use case and expected timing, timestamped. That timestamp settles every later argument about who was first.
Against existing customers, open opportunities, and other partners' live registrations. The partner sees the result at submission, not a week later.
Length set by partner tier, extended by logged activity, with warnings before it lapses and a visible lapsed state afterwards.
Their own referrals only, with exactly the fields you choose to expose, which removes most of what a partner manager's inbox is made of.
Won with a value and a date, or lost with a reason, which is what the payout is calculated from.
Eligible once your condition is met, grouped by partner, approved by a named person, exported and marked paid.
A referral tracker is not a shared spreadsheet of leads. It is four parts, and the second is the one that determines whether partners trust the programme.
The partner submits an account, contact, use case and expected timing. Timestamped, because the timestamp is what settles every later dispute about who was first.
An automatic check against existing accounts, open opportunities and other partners' active registrations, producing an accept, reject or review outcome with the matched record shown.
How long an accepted registration is protected, what activity extends it, what happens when it lapses, and who gets notified before it does.
The commission or fee owed per closed deal, by partner tier, calculated when the outcome is final rather than when the deal is optimistic.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
The submission, and whether you honour it.
In this Helix project, build me a partner referral tracker.
A partner submits a deal: their company, the prospect company and domain,
a contact, the country, the use case, an estimated value and expected
timing. Timestamp it, because that timestamp is what settles every later
dispute about who found the deal.
Then the part the whole programme lives or dies on. Check the submission
against three things: our existing customers, our open opportunities, and
other partners' active registrations. Match on email domain first and
company name second, because company names typed into a form almost never
match what is in our CRM and domains usually do.
Three outcomes. Clean, accept it. An existing customer, reject it with a
stated reason. A partial match, send it to a person with the matching
record shown next to it. Never reject silently: a rejected referral needs
a reason the partner can read.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Match on domain before company name. This one detail is the difference between deduplication that works and deduplication that annoys everybody.
The protection window, and the notifications that make it real.
On acceptance, set a protection expiry from a window I configure per partner
tier, say 90 or 180 days.
Let a partner log activity against the referral, and let activity extend
the window by a set amount up to a maximum, so a partner working the deal
keeps it and a partner who registered and vanished does not.
Notify the partner and the partner manager at intervals before expiry, and
again on the day it lapses. A window that expires without warning is worse
than having no window at all.
When it lapses, move it to a lapsed state that stays visible in history
rather than deleting it. Those records are how I find out whether the
window length is right.Removing the email that asks what happened to that lead.
Now the partner-facing side, and be careful with it.
A partner signs in and sees only their own referrals: status, protection
expiry, last update, and a running summary of what they have submitted,
what was accepted, what closed and what they have earned.
Make the visible fields a configuration rather than a code decision. Some
programmes share pipeline stage with partners, some share only open, won
or lost, and I want one app to serve both.
Never expose deal amounts, other partners, or internal notes in that view.
Everything a partner can see should be something I chose deliberately.
Show the deduplication result at submission, so a partner learns
immediately rather than a week later.Paying on money received, not on optimism.
Link each referral to an outcome: won with a value and close date, or lost
with a reason.
Calculate the payout from the partner's tier rate against the value I
designate as commissionable, which is often not the total contract value.
Make that an explicit field rather than an assumption.
Then gate eligibility on a condition I set, and default it to invoice
paid rather than deal closed. Paying on closure eventually means asking
someone outside the company to give money back, which costs more goodwill
than the delay costs patience.
A payout run: everything eligible in a period, grouped by partner,
approved by a named person, exported, marked paid. Plus acceptance rate
per partner, which is the number that tells me whether a partner
understands who we sell to.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Check submissions against existing customers, open
opportunities and other partners' registrations, and link closed outcomes
back.
<Okta>. Authenticate internal users, kept strictly separate from how
partners sign in.
<NetSuite>. Confirm an invoice was actually paid before a payout becomes
eligible.
<Gmail>. Tell a partner their registration was accepted, or rejected with
a reason they can read.
<HubSpot>. Some partner programmes run on a separate CRM from the direct
team. Read registrations from there too.
<DocuSign>. Check the partner agreement is signed and current before a
payout becomes eligible.
<Stripe>. Confirm the invoice was actually collected, if payouts are gated
on cash rather than closure.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This one has people outside your company signing in, so set Access Control carefully before sharing: a partner must see their own referrals and nothing else.
Deduplication is the whole trust question, and it can only work if the app can see your live pipeline.
Salesforce
Check submissions against existing customers, open opportunities and other partners' registrations, and link closed outcomes back.
Okta
Authenticate internal users, kept strictly separate from how partners sign in.
NetSuite
Confirm an invoice was actually paid before a payout becomes eligible.
Gmail
Tell a partner their registration was accepted, or rejected with a reason they can read.
HubSpot
Some partner programmes run on a separate CRM from the direct team. Read registrations from there too.
DocuSign
Check the partner agreement is signed and current before a payout becomes eligible.
Stripe
Confirm the invoice was actually collected, if payouts are gated on cash rather than closure.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It exposes some of your pipeline to people outside the company and decides what partners get paid, so how it is run is the larger half of the job.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
This app has internal and external users. SSO plus scoped access is what keeps a partner to their own referrals, which is the difference between a portal and a leak.
App Security
Deduplicating against live pipeline and linking closed outcomes needs real CRM access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It registers deals partners bring you, checks them against your existing pipeline, protects accepted registrations for a defined window, and calculates what you owe when they close. Its real job is settling who found a deal, with a timestamp.
Match on email domain first and company name second, against existing customers, open opportunities and other partners' active registrations. Auto-accept clean submissions, auto-reject existing customers with a stated reason, and route partial matches to a person.
The period during which an accepted referral is credited to the partner who registered it. It needs an explicit length per tier, rules for what extends it, notifications before it lapses, and a visible lapsed state rather than a silent deletion.
Make it a configuration rather than a code decision. Some programmes share pipeline stage with partners and some share only open, won or lost. Deal amounts, other partners and internal notes should never appear in a partner view.
On a condition you control, usually invoice collected rather than deal closed. Paying on closure means occasionally asking someone outside your company to return money, which costs more in goodwill than the delay costs in patience.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your deduplication rule and your protection window, and partners will remember both.
Sales and RevOps
Route discount requests by depth and deal size, give approvers the context to decide in minutes, and keep a record of every exception granted. Prompts to build it, and what it takes to run it.
Sales and RevOps
Calculate commission from the plan rather than from a spreadsheet nobody can audit, show every rep how their number was reached, and handle the disputes as data. Prompts to build it, and what it takes to run it.
Legal and Compliance
Tier vendors by the risk they actually carry, ask each tier only what it warrants, track findings to closure, and re-review on a schedule. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.