Why attribution is a code and not a cookie
Most referral programmes track attribution with a cookie: the partner shares a link, the link sets a value in the browser, and if the visitor converts within some window the partner gets paid. It works until it does not. Cookies expire. People clear them. Browsers block them by default now. The client researches on their phone in the van and submits from the office desktop, and the attribution evaporates somewhere in between.
When that happens the partner does not get a smaller fee. They get nothing, and they have no way to prove they should have got something. Then they stop referring, which is the correct response to a system that loses their work.
So attribution here is a code the client types. It survives a device change, a three-week gap, a cleared browser and a forwarded email. It has one real failure mode, which is the client not entering it, and that is a failure the partner can prevent by putting the code in the introduction.
What the token looks like and where it goes
A token is BETR-XXXX-XXXX. The character set deliberately excludes I, O, 0 and 1, because these get read out on the phone and written on the back of a business card, and a code that cannot survive being spoken aloud is a code that generates support tickets. Spacing and case do not matter: betr llzt wbv6 resolves to the same token as the printed version.
The client enters it in one field at the bottom of the scope form, which says plainly what it is for: it is how the partner gets paid, and it costs the client nothing. There is no discount attached and no penalty for leaving it blank. We are not going to pretend the code benefits the client when it does not; it benefits the person who sent them, which most people are happy to support once you say so.
Strict about payment, loose about the lead
The token system has two jobs that pull in opposite directions, and it resolves them in opposite ways on purpose.
Paying the right person is strict. A token only earns commission if it matches the register exactly, after normalisation, and is still active. A well-formed code that is not in the register does not become payable because it looks plausible. Paying a commission to the wrong partner is not a rounding error; it is money out the door and a conversation with the partner who actually made the introduction.
Capturing the lead is loose. A wrong token never blocks a submission. The client came to buy something. Losing their enquiry to punish a typo would be a self-inflicted wound, and it would punish the wrong person anyway. The enquiry lands, the code is stored exactly as typed, and it is flagged as unrecognised so a human resolves it. In practice that resolution is usually a one-line message to the partner asking whether this was theirs.
What the partner is paid, and when
A referral partner takes 10% of the build fee plus 10% of the managed fee for twelve months, paid within seven days of the client's payment clearing. That is the same figure published on the partnerships page, and the code that calculates it reads those rates directly, so the two cannot drift apart.
The commission is calculated at the moment the scope arrives and travels with it, which means the internal record already says who is owed roughly what before anyone has replied. It is labelled as what it is: an estimate on an estimate. The build price is a band, and the job has not been won yet. A partner who is told a firm number on an unwon job is being set up for a disappointment.
White-label works differently
White-label partners do not earn a commission, because they are not being paid a finder's fee. They buy at 60% to 65% of list and set their own price, and the margin is theirs. The token still exists and is still worth using, because it tells us the enquiry came through a partner channel and should be handled accordingly, but no commission is calculated against it.
If you want the client relationship and the pricing control, white-label is the shape. If you want to make an introduction and stay out of delivery, referral is. The partnerships page argues both sides, including the one where you should not become a partner at all.
Getting a token
Tokens are issued to named partners, not generated on request by a form. That is a deliberate friction: a referral programme that mints codes to anyone who asks gets farmed within a month, and then every enquiry arrives carrying a code nobody can vouch for. Talk to us on the partnerships page and you get a code, a written statement of the terms, and a record of which introductions were yours.