What head office sees
shouldn't be the version
partners chose to reportA three-tier partner management system running on the client's own servers
Status
Live
Deployment
Client's own servers
Learning curve for partners
0 · no app, no new password
Data through third-party SaaS
0
What's actually wrong
Not a missing system — facts that can't reach head office
Head office sees the version partners chose to report
Who the customer is, how far the deal has got, whether the money arrived, how the month is going — those facts sit with dozens or hundreds of people and travel upward only when they fill something in. How often, how accurately, and whether at all depends on the person.
By the time it's consolidated, the moment when it could have changed a decision has usually passed.
Ownership is decided by memory and chat history
Two people working the same customer isn't an accident in a distributed organisation, it's routine. But it usually surfaces on the day the deal signs — and at that point neither can back out without writing off months of work.
The trust lost in one ownership dispute costs far more than the deal it was about.
Performance and commission only exist at month end
Consolidated at month end, reconciled at month end, ranked at month end, and only then does anyone know what they earned. For the thirty days in between, the person doing well and the person doing badly get identical feedback: none.
For a team finding their own customers, feedback delayed by thirty days is roughly the same as no feedback.
All three are one sentence: head office isn't managing the business, it's managing a stack of late reports.
One entry point
The biggest risk here isn't technical — it's that nobody uses it
So we didn't build a client application. The entry point is WeCom — the messaging tool they were already in every day. No new icon, no new password, no “everyone please install this”. A partner finishes a visit and sends a message the way they always would, in ordinary language. What comes back is a screen of organised information waiting for them to confirm.
Partners don't have to change what they do
After a visit they say a sentence the way they'd normally say it — not open a system, find a form, pick from dropdowns and fill in required fields.
The only action left for them is confirming
What comes back is a screen of information already organised. Glance at it, accept or correct. That step is a deliberate human checkpoint: only what's confirmed counts.
So the records contain nothing that needs cleaning up later
Every line entering performance figures and commission was confirmed by the person themselves, at the time. That's less work than any after-the-fact validation, and far less arguable.
That confirmation is a quality gate by design, not an extra tap: only confirmed data enters performance figures and commission, so the records contain nothing that needs cleaning later and no arguments about whether a number counts. How the recognition and filing work is written out in the proposal — not expanded on a public page.
Ownership
Duplicate coverage is resolved as it happens, not on signing day
Locked on first entry, stopped on the second
When a second person enters the same customer, the system produces a conclusion immediately and notifies both of them and their managers. The disagreement is on the table while it's still small, instead of waiting for settlement day. By settlement day it isn't about ownership any more, it's about money.
The clearest change after launch wasn't fewer disputes
It was partners racing to enter customers first — because entering locks it. A rule that only holds while management chases it will eventually slip; a rule that generates its own incentive holds by itself. That's the design decision in here we're happiest with.
What the system manages
Six areas, each one previously relayed by people
Organisation and permissions
Head office, region, partner and finance each see a separate slice. The directory follows the org chart, so joiners and leavers don't mean maintaining a list by hand. Every action is attributed — who changed what, when, is recoverable afterwards.
Customer records
A full record from first contact through signature, payment and renewal, with stages defined by your business rather than a generic template. Filterable on any dimension and exportable at any time.
Orders and payments
Order status, payment logging, and payments matched to orders automatically. A signed deal with no corresponding money arriving is something the system notices by itself.
Live performance figures
Individual, regional and company-wide standings available at any moment, with nobody producing a consolidation spreadsheet — that particular job stops existing once this is running.
Automatic commission calculation
Tiered rates, regional coefficients and deductions are all supported. The moment an order reaches signed, the estimated commission is pushed to the person; at month end finance reviews and confirms in bulk, and the statement generates once.
Conversation archiving and compliance
External communication archived and sensitive wording flagged, using the official archiving capability available after corporate verification — not scraping. Whether it's on, and how wide it reaches, is yours to set.
Of the six, commission moves motivation most, and not in the way a leaderboard does: letting someone see what they earned as it happens beats making them reconcile it at month end. A leaderboard means something to the top few. Visible earnings mean something to everyone.
Six alert types
Not more alerts — the right person for each one
Follow-up overdue
A customer sitting untouched for too long — the most common and most expensive way to lose one.
Large deal pending review
The value crosses the line you set, so someone looks at it before it goes further.
Payment overdue
Signed, but the first agreed payment still hasn't arrived.
Payment mismatch
The order shows as signed while nothing corresponding has landed in the company account.
Performance drop
A person or a region falling abnormally this month — known as it happens, not at the quarterly review.
Compliance risk
Wording that shouldn't appear in external communication has appeared.
Management gets a separate daily brief: what happened yesterday and which few things need attention today, written as something a person reads straight through, not a report they have to go and interpret. A report waits to be opened. This arrives, and by the end of it you know what to do.
The same month
Inside the system, and on reports and consolidation sheets
Inside the system
- ✓The customer is in the records within minutes of the visit ending, confirmed by the person who made it
- ✓A second person entering the same customer gets a conclusion on the spot, not on signing day
- ✓On the day it signs, the person can already see roughly what they earned
- ✓Rankings, regional performance and overall progress are visible at any time, with nobody consolidating anything
- ✓A payment that doesn't match its order is found by the system, not during month-end reconciliation
- ✓At month end finance reviews calculated results rather than a pile of unentered material
On reports and consolidation sheets
- ✕Notes in a notebook after the visit, entered into a form later, when someone remembers
- ✕Duplicate coverage surfaces on signing day, when there's no graceful way out
- ✕What you earned this month is known in the middle of next month, once reconciliation finishes
- ✕Head office wants numbers, so it chases regions, which chase partners
- ✕Whether payment arrived is established by finance comparing transactions line by line
- ✕The last days of the month have the whole team doing one thing: assembling scattered numbers into a sheet
Running on the client's own servers
The default shape, not a paid upgrade
The data doesn't leave your server room
Customer records, activity history, orders and payments are physically stored on your own servers and pass through no third-party SaaS. That isn't an option or an upgrade — it's the default shape of this system.
Someone else can take it over
Built entirely from common open-source components, with no proprietary parts only we understand. Source code into your repository, along with deployment documentation, a runbook and training — a delivery goal, not an add-on service.
After handover we can't get in
No server credentials held, no back-door account, no managed hosting. When you want help diagnosing something you grant temporary access and revoke it afterwards, and the whole exchange is recorded in your own logs.
Large models are used in a few narrow places
All through APIs, so you don't need to run GPU infrastructure; the API account is funded by you directly, with nothing collected or marked up by us. Which step sends what, and to whom, is listed item by item at the proposal stage — and you can reject any of it.
One more thing whose value only shows on launch day: historical customer data was cleaned, de-duplicated, assigned an owner and migrated in together. So the new system was full on day one rather than empty — and an empty system teaches everyone to carry on the old way until it has data in it, after which it never gets any.
When this doesn't apply
This has a clear boundary
One tier, everyone in one office
If people sit together and can ask across the desk, most of this value disappears. What it treats is a specific condition: people distributed, with facts only travelling upward by self-report.
A handful of partners, all conscientious
Five or six people meeting weekly and volunteering updates can genuinely be handled with a spreadsheet and attention. The value here rises with headcount and tiers; too early, and it costs more to run than it saves.
Commission is still negotiated deal by deal
Who takes priority, how rates are calculated, what doesn't count — somebody has to be able to decide those. Building before they're settled just moves the argument somewhere harder to change.
What you'd end up with
A business line that doesn't run on self-reporting
This manages people running your business
If what you need to manage is external partners selling for you — creators, dealers, channels — that's a different shape entirely: tracking, attribution, commission, in-store visits.
The same organisation layer answers questions
Once organisation and permissions exist, internal Q&A and document retrieval can share the same foundation — permissions follow the org chart, and restricted content isn't retrievable rather than hidden.
One piece first is fine
You don't have to take the whole line. Customer records and ownership can go live first, with commission and alerts attached later — the interfaces are built in from the start.
Questions
What people ask about this one
01We're not in that industry. Does this still apply?+
The shape of this has little to do with industry and a lot to do with structure: do you have people who don't sit at head office, finding and working their own customers, whose performance and earnings have to be calculated by rule. If both are true, the shape fits. Only two things genuinely have to be rebuilt for your business: the language it recognises (how your people actually talk, and about what) and how customer stages are defined. Organisation and permissions, ownership locking, commission rules and the alert matrix are all common structure. The diagnostic starts by judging how far your business is from that shape — and if it's far, we'll say so.
02Will partners resist it?+
That depends on whether the system asks them to do one more thing or one less. Here the compliant path is made easier than the old one: saying a sentence records the customer faster than writing it in a notebook; they can see roughly what a deal earns them on the day it signs rather than at month end; and entering a customer locks ownership, so getting there first is in their interest. Which means the deciding factor isn't how hard it's pushed — it's whether what they open on day one is the thing they were already using.
03Where does the data live? Can you see it?+
Physically on your own servers, passing through no third-party SaaS. We don't operate it and we don't keep a back-door account — after handover we can't get in either. When you want help diagnosing something you grant access temporarily and revoke it afterwards, with the record in your own logs. Which large model is used, at which step, and what it would send is listed item by item at the proposal stage, and you can reject any of it.
04What if it interprets something wrongly?+
Nothing goes into the records straight from interpretation. What comes back to the person is a screen of information to confirm — glance, accept or correct — and only what's confirmed enters performance figures and commission. So errors never flow into the numbers. That checkpoint is deliberate, not a temporary stage, and the amount needing correction falls as your own language accumulates.
05Can we maintain it ourselves?+
Yes, and that's one of the delivery goals. Alert conditions, commission rules, the org structure and who gets notified are all configurable in the back office, and the orchestration layer is visual enough for your own technical people to adjust later. Source code goes into your repository along with deployment docs, a runbook and training.
06Does adding a rule or a new role later cost extra?+
Yes. This is a billing rule written into the contract at signing rather than raised mid-project, and it has two halves. Day-to-day maintenance — thresholds, commission percentages, adding people to roles, changing notification targets, version upkeep, routine checks and incident response — your own technical people can carry, or you can buy an annual maintenance subscription. A new role type, a new business line or connecting a new business system is new development, scoped and priced as a new project. Splitting it this way keeps the accounting honest: folding new work into a maintenance fee either inflates the fee or means the new work gets done carelessly.
Next