Every growing company ends up answering the same business questions over and over: is checkout completing? Are we collecting what we invoiced? Is the support queue under control? The question rarely changes. What changes is how the company chooses to keep it answered — and each approach carries a predictable failure mode.

There are three. None of them is wrong. Most companies are running all three at once without noticing.

1. The ticket: answer it once

The question goes to an analyst as a ticket. A query is written, a number is produced, the ticket closes.

This is the fastest path to an answer, and the slowest path to a capability. The answer expires the day it ships, because it is a snapshot of a system that keeps moving. The query lives in someone’s editor, so when the question returns next quarter — and it will — the work starts again, slightly differently, by someone who remembers it slightly wrong.

The failure mode: the answer is correct once, then quietly stops being an answer.

2. The dashboard: answer it everywhere

The question becomes a dashboard. Panels are added, filters appear, the team checks it every Monday.

Dashboards fail earlier than people think — not at the query, but at the definition. “Overdue invoices” measured from the due date, the reminder date, or the promise to pay are three different numbers, and the dashboard does not know which one the business agreed to. When the numbers disagree, every team defends its own panel, and the meeting becomes an argument about whose query is right rather than what to do.

The failure mode: many answers, no agreement, and no way to notice that the definition itself drifted.

3. The contract: agree it once, keep it live

The third approach is less popular because it front-loads the hard part. The business writes down what counts — the population, the authoritative outcome, what is excluded — and that definition is versioned and reviewed like code. Instrumentation emits events against it, and the answer stays live from then on. When the definition changes, the change is a diff someone approved, not a memory someone lost.

This is what a business commitment actually is: an agreement with evidence attached. It is more work than a ticket and more discipline than a dashboard. The payoff is that the Monday meeting stops being about whose number is right and becomes about the decision the number exists to inform.

The failure mode, to be honest: if nobody owns the contract, it decays into documentation. Contracts need a reviewer the way dashboards need an owner.

Which one are you running?

A useful audit: take the three questions your leadership asks most often, and for each one ask — was the definition ever written down? Who can change it? What happens to the answer when the underlying system changes?

If the answers are “no”, “nobody knows”, and “someone re-runs the ticket”, you are running approach one with approach two’s furniture.

That is the gap Soltura exists to close: it starts from the agreed question, proposes the instrumentation as a reviewed pull request, and keeps the answer live — with the measurement honest enough to say “this cannot be concluded yet” instead of inventing a number. If that is the kind of problem you have, the live demo shows one full answer end to end.