A partner network that provisions itself

The challenge

The company sold through partners — hotels, agencies and operators who referred customers and earned commission. Commercially the model worked. Operationally it did not scale.

Each new partner needed their own landing pages, their own pricing arrangement, referral tracking that survived the customer's whole journey, and a commission rule that finance could later reconcile. All of it was configured by hand, by one person who understood how the pieces fitted together.

The result was a queue. Partners who had already signed waited to be switched on, and the business was in the strange position of having sales it could not turn into revenue quickly.

The engineering problem

The obvious framing was "automate the onboarding". The real problem was narrower and harder: nobody could reliably answer the question what is this partner owed, and why.

Attribution and commission had been assembled incrementally. Referral parameters were carried in URLs, partner identity was inferred in more than one place, and the commission logic lived partly in configuration and partly in the code that processed orders. It usually produced the right answer. It could not explain itself.

Automating provisioning on top of that would have made the ambiguity faster rather than smaller.

The approach

We took the commission engine first, before touching onboarding.

Attribution was made explicit and durable: a referral is captured once, stored against the order, and never re-derived later from something that might have changed. Commission became a calculation over recorded facts — order, partner, rate, date — that can be recomputed from history and produces the same answer every time.

Only then did we build the generator. Given a partner record, it provisions the pages, applies the pricing arrangement, creates tracking links, and registers the commission rule. The output is the same shape every time, which is what makes it auditable.

The solution

Onboarding a partner became a data entry task followed by a generation step, rather than a week of configuration. The generated output is deterministic, so a partner set up in March looks structurally identical to one set up in September.

Commission became reconcilable. Finance can take a period, recompute it from the recorded orders, and compare — which is a materially different relationship with a number than being told what it is.

The work was delivered as isolated extensions rather than modifications to the core platform, so the client's existing system kept its upgrade path. That constraint made a few things more awkward to build and made the result substantially safer to own.

Technology

• Deterministic partner provisioning from a single source record
• Durable referral capture stored against the order rather than re-derived
• Commission calculation as a recomputable function of recorded facts
• Bidirectional synchronisation with the operational database used by the commercial team
• Delivered as isolated extension modules, leaving the core platform upgradeable

Business value

Partner activation stopped being a queue. More usefully, the commercial team could answer partner questions about commission with a calculation rather than an assurance — which changes the tone of those conversations considerably.

The specific commercial figures belong to the client and are not published here.

Key learnings

Fix the thing being automated before automating it. Provisioning was the request. Attribution was the problem. Automating first would have been faster to demonstrate and worse to live with.

Report what you find, even when it is inconvenient. The attribution gap was awkward to raise mid-project. Not raising it would have meant delivering a system that computed the wrong answer very reliably.

Isolation is worth some awkwardness. Building alongside the core platform rather than inside it cost some elegance and preserved the client's ability to take vendor updates. That trade is almost always worth making.