The schema checklist
Attribution needs a discrete, dated, recorded event. Acquisition has one — the deal closed, on a date, against a source. Onboarding, adoption and renewal usually have nothing of the kind, so the partners doing that work leave no trace in the data. Six questions to find out what your own schema could answer today, before anyone changes a system.
Written for Customer Success, CX and RevOps leaders. You do not need the partnership team, and you do not need any partner data to answer these — the point is to establish whether the data could exist.
The six, in short
- 1A partner is a recordNot a name typed into a field
- 2Linked to the customerNot only to the deal
- 3Post-sale work has a dateThe missing event
- 4Enrolment is separate from the workOr the invisible partner stays invisible
- 5Outcomes carry the date they were readSo customers compare at the same age
- 6Needs are declared, and attributedThe denominator
Answer each about the system you would actually query. Twenty minutes with the person who owns the CRM is usually enough.
Six questions
Answer each one about the system of record you would actually query — the CRM, the CS platform, the PSA, whichever holds the truth. "We could work it out from notes" is a no.
1 · Is a partner a record, or a text field?
Ask: can you list every customer a given partner has touched, by selecting the partner, not by searching free text?
Why it matters: a partner name typed into an opportunity field cannot be joined to anything. Everything below depends on this one being a yes.
If it is a no, stop here: the rest of the checklist is about edges you cannot draw yet.
2 · Is the partner linked to the customer, or only to the deal?
Ask: when a deal closes, does the partner link survive on the customer record, or does it stay on the opportunity?
Why it matters: a link that lives on the opportunity expires at the moment the relationship starts mattering. This is the single most common reason a programme can report sourcing and nothing else.
3 · Is post-sale partner work recorded, with a date?
Ask: for an implementation, a support engagement, a QBR, a training session or a renewal conversation run by a partner — is there a row, with a customer, a partner and a start date?
Why it matters: this is the missing event. Without a date you cannot tell whether the partner arrived before the outcome or after it, which is the difference between a cause and a coincidence.
An end date, or a blank end date meaning "still running", is worth having too — it separates a relationship that continues from one that finished years ago.
4 · Is programme enrolment recorded separately from the work?
Ask: can you tell the difference between "this partner is in our programme" and "this partner did this work"?
Why it matters: when the two are the same field, a partner who is doing the work but is not enrolled is invisible by construction — and that is the partner most audits turn up first.
5 · Is the customer outcome recorded, with the date it was read?
Ask: retention, expansion, a reference, a health status — is each stored against the customer with the date it was set, not just as today's value?
Why it matters: a status with no date can only be compared across customers on the day you look. With a date you can compare customers at the same age, which is what separates a channel that retains better from a channel whose customers are simply younger.
6 · Is what the customer needed recorded, and who met it?
Ask: is there a list, per customer, of what they needed from you and your partners — and against each, who delivered it?
Why it matters: without a declared list of needs there is no denominator, and completeness cannot be counted honestly. This is the question most organisations answer last, and the one that turns an opinion about coverage into a number.
Reading your answers
Count the yeses. The point is not a grade — it is knowing which questions your data can already answer, and which one field would move you up.
One or two
You can report what partners brought in, and almost nothing about what happened next. This is the normal starting position, and it is the measurement gap rather than a failure of the team.
Three or four
You can see partner involvement after the sale and place a relationship on the depth it actually reaches. You cannot yet tie that involvement to what happened to the customer.
Five or six
The join exists. You can ask which relationships create and keep customer outcomes, and get an answer from data rather than from the account team's memory.
If you want the reasoning behind these six, it is in the published series: The Measurement Gap sets out why acquisition has an event and retention does not, and The Customer-First Framework sets out the depth levels and the lifecycle weights the audit uses.
What to do next
Run it on five real customers
The Five-Customer Audit is the same idea applied to a real book: pick five customers, map every partner that touched each lifecycle stage, registered or not, and compare. About an hour, and you keep the output.
The Five-Customer Audit →Let an export answer questions 1 to 4
The free readiness audit reads a partner-engagement export as it is, says what each partner does for your customers (sell, deploy or run), and says plainly which of these fields your file did and did not carry. Nothing is stored beyond the session.
Load an export →See what it looks like first
A click-through of the whole readiness audit on real screens — what to load, what it reads back, and what to check at each step.
How the audit works →