Six steps, in the order you'd actually do them

Decide what counts

For each client, name the handful of actions that mean the software is doing its job, and say how much of each you'd expect in a normal week. This is the only part that differs between clients — the rest of the model is identical everywhere.

Let the app report itself

The client's app posts one event per action to a single endpoint, authenticated with that client's ingest key. Retries are safe: the same metric, timestamp and actor is stored once, so a flaky connection can't inflate anyone's numbers.

A metric key nobody defined is stored and flagged rather than dropped. A new event type appearing is information — discarding it silently is how you find out six months later that tracking broke.

Ask the people using it

A short form on a one-click link — no login, under two minutes. Management and the people doing the work are asked separately, because the person who bought it and the person using it can disagree, and that disagreement is the most valuable thing on the page.

We generate the link. A human sends it. Nothing in here emails a client on its own.

Record what we get wrong

Outages, bugs, complaints and missed deadlines, logged against the client with what we did about them. They pull the score down while they're open, and they appear in the report alongside their resolution.

Score it, explainably

Four weighted inputs — usage, trend, feedback, incidents — combined into one number that always carries the evidence behind it. The weights are editable rows, not constants in code, and where the data is thin the score says so instead of guessing.

Hand over the report

Usage against expectations, what they said, what broke and how it was fixed, and the assumptions behind every figure. Printable. This is the artefact that goes into a renewal — a record rather than an opinion.