In two-tier distribution, nobody owns the partner's story

Ask a distributor's general manager who their best partner is and you will get an answer immediately. Ask them which partner was their best one eighteen months ago, and whether that is still true, and the answer slows down. Ask them which partner is becoming their best one, and the room goes quiet.

This is not a failure of attention. It is a structural property of two-tier distribution, and it is worth naming precisely, because most of the software sold into this problem is aimed at the wrong part of it.

Three parties, three partial views

In a two-tier channel, the vendor sees sell-in. They know what left their warehouse and whose purchase order it left against. They do not see what happened next.

The reseller sees the customer. They know who is renewing, who is expanding, who is quietly evaluating a competitor. They have no particular reason to tell anyone, and in most territories no contractual obligation to.

The distributor sits between them and sees transactions. Lines on invoices. A partner who bought, and a date, and a quantity, and a price.

Each party holds a real and honest view. No one holds the partner's story — the arc of a relationship across years, the moment the cadence started stretching, the attach that never got sold, the renewal that came due while everyone was looking at this quarter's number. The story is not missing because someone lost it. It was never assembled, because assembling it is nobody's job and no single party has the pieces.

The data is not the problem

The reflex, when a decision-maker cannot see something, is to ask for a report. Then a dashboard. Then a better dashboard.

But go and look at the ERP. The data is there. Every order, every line, every partner, every date, going back years. A distributor with a decade of history is sitting on a complete record of exactly the thing they cannot answer questions about.

What the record lacks is not rows. It lacks shape. An invoice line knows it is an invoice line. It does not know that it is the fourth consecutive month of a shrinking basket from a partner who used to buy weekly. It does not know that the hardware it describes carries a support term that expires in two months, and that somebody is quoting that renewal right now — possibly not you. It does not know that the partner buying storage from you has never once bought the networking that sits beside it in every deployment they do.

Those are not facts you can query out of a transactional schema, because they are not properties of a transaction. They are properties of a relationship, and the schema has no concept of one.

What an ontology actually is

Strip the word of its academic weight and an ontology is a small, boring, enormously consequential claim: these are the things that exist in this business, and these are the ways they can relate to each other.

A partner exists. A partner has a trajectory, not just a balance. A product sits in a family, and families have companions that are usually bought together and are conspicuous when they are not. A sale has a support term, and a support term has an expiry, and an expiry is a date on which somebody will be quoting — the only question is who. A partner's spend with you is a share of their spend somewhere, and the rest of that spend is not invisible; it is inferable from the shape of what they do buy.

None of that is in the ERP. All of it is true. An ontology is where you write it down in a form a machine can reason over, and it is the difference between a system that reports what happened and a system that can tell you what is happening.

Once the shape exists, the signals fall out of it almost for free. Decay is what a stretching cadence looks like when you have modelled cadence. Leakage is what an expiring support term looks like when you have modelled support terms. Whitespace is the companion product that is missing from a family you have modelled. The signal is not a clever query. It is a consequence of having said, out loud and in code, what a partner is.

The uncomfortable part

Everything above is an argument, and arguments are cheap. The honest position is that a methodology is worth exactly what it can be shown to have found, and we are early: we are measuring at our first deployments and we will publish what we find, including the parts that do not flatter us.

That is not modesty for its own sake. It is the same discipline the product runs on. A system built to surface what is really there — rather than to normalize it into a number that looks decisive — has to be willing to say we do not know this yet. A firm that will not say that about itself has no business selling a platform that says it about your data.

So: no percentages here. Not yet.

What we will claim is the diagnosis, because the diagnosis does not require our numbers to be true. Your channel data is not a reporting problem. It is a shape problem. And nobody — not the vendor, not the reseller, not the invoice — is holding the partner's story on your behalf.