Skip to content
Robbins Analytics.

For Ben Salter and Santosh Chandavaram

600 dashboards, and still not enough data. What changes in 90 days?

Teams need more data than has been built, and Ben estimates 600 dashboards already exist. Beneath them, Santosh asks whether each record is complete and correct. In 90 days the noise gets a name on it and the signal gets one way in: every Quick dashboard a recommendation, every new request a route.

  • By day 90: a recommendation or a named decision owner for every Quick dashboard.
  • Two endorsements needed: Ben endorses the program and Santosh the role, with each condition approved by its owner.

01 / The problem

Two problems, and the questions each one raises

  • Fast growth left hundreds of dashboards where a few dozen are needed, and many of those must be redone or hardened. That is the noise.
  • At the same time, the hunger for analysis keeps growing, and not enough of what teams need has been built. That is the signal, not getting through.

Too many dashboards

built fast, not yet reviewed

Not enough data

every team needs more than has been built

What do we actually have, and who is responsible for each piece?

Knowing what we have starts with a verified count: every dashboard checked against the system’s own records, with a named owner and its use.

Which dashboards overlap, which disagree on a definition, and which serve a need nothing else does?

Telling them apart means rationalizing the estate: comparing dashboards by purpose, not title, with evidence an owner can act on.

What prevents report sprawl after rationalization?

Sprawl stays away only if new work has one way in: a check against what exists before anything is built, and a recorded outcome.

Which current business problems does the existing reporting leave unanswered?

Finding the gaps means listing the business problems that matter now and checking each against what the existing reporting can answer.

How can each new request be shaped into a sharp, answerable business question?

Shaping a request means writing it down the same way every time: who is asking, what decision it serves, and who will own the result.

One answer to both: rationalize the reporting estate, then give every new request a business question and a check against what already exists.

What counts as the estate?
Quick reporting estate
Every dashboard, with the analyses, datasets and other Quick assets behind it.
Data and analytics estate
The sources, pipelines, definitions, standards, documentation and working practices that produce and govern the data.

02 / The answer

Project Clear Signal: three gates, each ending in named decisions

Three gates, each turning down the noise: count what exists, rationalize it, then keep the signal clear through one way in. Proposed at days 30, 60 and 90; steps overlap at the edges.

Ninety days, three gates, a decision at each

A 0 to 90 day axis with gates at days 30, 60 and 90: Inventory, Rationalize, Operationalize. The selected gate is filled. DAY 0 DAY 30Inventory DAY 60Rationalize DAY 90Operationalize A 0 to 90 day axis with gates at days 30, 60 and 90: Inventory, Rationalize, Operationalize. The selected gate is filled. DAY 0 DAY 30Inventory DAY 60Rationalize DAY 90Operationalize

Days 1–30 · Inventory

AnswersThe count and ownershipDashboards that don’t answer

How: learn how Quick holds the estate, take the first full count, map each dashboard’s owner and use, and audit the data beneath it: sources, definitions, standards, practices.

Output: a reconciled count checked against Quick’s own records, an ownership map, and a recommended first domain. Claims readiness is the leading candidate, tested on the evidence.

  • Ben confirms the first domain.
  • Santosh confirms the technical boundary.

Days 31–60 · Rationalize

AnswersMany overlap, disagree, or need redoing

How: compare duplicates by business purpose, not title, and put every open decision in front of its owner.

Output: a ledger with each dashboard’s recommendation, and an aged decision queue: every open decision, its owner and how long it has waited.

  • Owners keep, consolidate or propose retirement.
  • Santosh confirms the technical evidence behind each recommendation, and which data fixes engineering takes.
  • Ben confirms the order the recommendations are worked in.

Days 61–90 · Operationalize

AnswersRequests arrive as problemsA one-time cleanup can grow back

How: embed definitions and owners, open the way in for new requests, and run one real request through it end to end.

Output: the ledger; the way in for new requests, up and running; and one real request taken through it end to end with the requester’s dated acceptance, or that milestone marked unmet.

  • Ben accepts the way in and names who runs it.
  • Santosh confirms the engineering handoff.

A slipped gate moves the forecast and shows the blocker.

By day 90, every dashboard has a recommendation or a named owner who owes one, and every new request has one way in: a clear signal.

Why is claims readiness the leading first domain?

Claims readiness leads the shortlist because it is the clearest case of existing dashboards not answering a current problem.

  • The gap: a completed ride is not yet a ready claim, and a missing downstream record fails without an obvious error.
  • The method: the data and analytics audit traces that gap back to its sources.
  • The decision: day 30 tests the candidate on the evidence; it is not chosen in advance.

03 / In parallel

Cleanup and new requests run at once, and meet in one shared record

Both lanes feed the same record: the reporting estate is rationalized while new requests keep arriving, and the current team keeps building throughout.

Updates merge into the estate at each gate; after day 90, one line

The same 0 to 90 day axis. Lane 1, the existing reporting estate, runs as the main line: counted at day 30, compared and recommended at day 60, decided at day 90. Lane 2, reporting estate updates, runs beneath it and merges into the main line at each gate. After day 90 only one line continues, the Register. The selected window is emphasized. DAY 0 DAY 30 DAY 60 DAY 90 AFTER LANE 1 · EXISTING REPORTING ESTATE the Register LANE 2 · REPORTING ESTATE UPDATES Counted Compared, recommended Decided Three merges, then one line: nothing built during the project is left outside the count. The same 0 to 90 days, top to bottom. Lane 1, the existing reporting estate, runs as the main line on the right: counted at day 30, compared and recommended at day 60, decided at day 90. Lane 2, reporting estate updates, runs on the left and merges into the main line at each gate. After day 90 only one line continues, the Register. The selected window is emphasized. LANE 2 · UPDATES LANE 1 · ESTATE DAY 0 the Register AFTER DAY 30 Counted DAY 60 Compared,recommended DAY 90 Decided Three merges, then one line: nothing built during the project is left outside the count.

Days 1–30 · Count

Existing reporting estate

Learn how Quick holds the estate and take the first full count: each dashboard’s owner and use, and the data beneath it.

Reporting estate updates

Requests for new builds or updates keep coming and are built as today. Nothing changes for requesters yet; what gets built is picked up at the day-30 gate.

Days 31–60 · Rationalize

Existing reporting estate

Compare duplicates by business purpose, not title, and give every dashboard a recommendation with evidence. The day 0–30 updates are rationalized with it.

Reporting estate updates

Still built as today. Everything built in days 0–30 joins the count already mapped and is rationalized with the estate in this window; what is built now is picked up at day 60.

Days 61–90 · Decide, and open the way in

Existing reporting estate

Embed definitions and owners; owners decide. The day 30–60 updates are rationalized with it, and the day 60–90 updates are captured and rationalized at day 90.

Reporting estate updates

From day 61 every request takes the way in below: written as a business question, checked against what exists, closed with one of five outcomes. From day 90 the Register is the one record for every request.

Both lanes read and write the Register: one linked record of every Quick asset, every request, every decision and every exception, each with an owner.

The way in, from intake to acceptance

One path for every request. An evaluator checks each request against the Register for an existing answer and drafts its record. It starts on day 61; until then, requests keep coming as they do today.

  1. Intake question, decision, requester, audience, value, urgency, data class, format
  2. Triage reuse result, outcome, priority, owners, scope, definition of done, acceptance criteria
  3. Close review evidence, accepted or rejected with date, support owner, review date

Five outcomes

  • Reuse: an existing answer fits, and the request closes.
  • Update: an existing solution takes the change.
  • Build: the current team builds something new.
  • Fix the data: the gap is upstream, so it goes there.
  • Decline or defer: recorded with a reason.
How the way in opens, and what happens to work already in flight

The way in opens at day 61, with a light Register open earlier. Work already in flight keeps its path and is logged. Where no technical gate exists, a manager checks releases. Exceptions go to a visible register, and at day 90 a sample of new assets is matched to request records.

Until day 61, whatever gets built is caught at the next gate; from day 61, every request is in the record from the day it arrives. Nothing is built twice.

What would an AI evaluator do, and what would it never do?

An AI helper may take the evaluator’s first pass. It is adopted only if its first pass matches the evaluator’s own checks, and running the way in by hand stays the fallback.

Does

  • Checks the Register for an existing answer.
  • Drafts the request record from the requester’s own words.

Never does

  • Make a decision. A named person reviews every draft.
  • Run outside SafeRide’s approved AI platform or before security approval.

In month 1 the design goes to the forward-deployed engineers Ben described, to ask whether and how they would build it. If that team or its capacity is not there yet, the way in runs by hand.

04 / The estate

Every Quick dashboard ends in one of four states

Each state is a recommendation backed by evidence. The owner’s decision is recorded separately and shown beside it, with its age.

One count, four states, one decision each

Every Quick dashboard, counted and compared, flows into one of four states: keep; consolidate or harden; propose retirement; waiting on a decision. Each state flows to the owner, who decides. The selected state is emphasized. Every Quick dashboard, counted and compared Keep Consolidateor harden Proposeretirement Waiting ona decision The owner decides; the decision is recorded beside the state, with its age. Every Quick dashboard, counted and compared, flows into one of four states: keep; consolidate or harden; propose retirement; waiting on a decision. Each state flows to the owner, who decides. The selected state is emphasized. Every dashboard, counted and compared Keep Consolidate or harden Propose retirement Waiting on a decision The owner decides; the decision isrecorded beside the state, with its age.

Keep

  • When it appliesIt is used, and does a job no other dashboard does.
  • ExampleA day-of-issues dashboard: today’s trips by status, late pickups, driver no-shows and open member complaints, refreshed through the shift and worked from the dispatch desk.

Consolidate or harden

  • When it appliesConsolidate when several dashboards answer the same question. Harden when one is needed but fragile: no owner, a manual refresh, or a disputed definition.
  • ExampleThree ride-volume dashboards, one each for operations, finance and account management, each counting a completed ride a different way. Candidates to combine once their owners approve one definition.

Propose retirement

  • When it appliesUse appears low within the verified observation window and the owner confirms no required, scheduled, embedded or contractual use; or its purpose is served elsewhere.
  • ExampleA tracker for a project that has ended, once its owner confirms nothing still depends on it.

Waiting on a decision

  • When it appliesThe evidence is ready but the owner has not answered, is not yet identified, the evidence is incomplete, or teams disagree. It shows whose call it is and how long it has waited.
  • ExampleFinance and operations each keep a cancellation-rate dashboard with a different denominator, and neither owner will adopt the other’s. The decision goes to the manager above both, and the queue shows how long it has waited.

Evidence recommends, owners decide, and nothing waits in the dark: every open decision shows whose call it is and how long it has waited.

How are dashboard owners asked, and where does program reporting live?

Each owner gets a short plain email, with no patient data or usage identities, linking to one page per dashboard on SafeRide-approved hosting, visible only to its authorized recipients.

The page shows

  1. what the dashboard is, and its purpose;
  2. the evidence: use, overlap, definition conflicts;
  3. the recommended resolution and its alternatives;
  4. the options: keep, consolidate or harden, propose retirement, or talk;
  5. the response target.
  • Answers are recorded under a verified identity. No answer means pending, never accepted.
  • Owners and technical staff check the facts; the Quick team builds nothing for it.
  • Program instruments: these pages, the Register and the gate packets are built in HTML, separate from business dashboards. They sit outside the Quick estate, are never rationalized, live on SafeRide-approved systems and carry one tracking record. Their future is decided at day 90.

05 / Endorsements

Endorsing the plan is not approving its conditions

Both must endorse; each condition is still granted by its owner. Endorsing does not grant any of them.

If a condition is not granted, its milestone moves and the blocker is shown.

Two endorsements open the door. Eight approvals, each with a name on it, keep the clock running; a missing one moves a milestone, never the blame.

06 / Honest edges

What is not promised, and what day 90 proves

What this proposal does not promise, and what day 90 can be checked against.

Not promised

  • Deleting anything on my own authority.
  • Building business dashboards.
  • Replacing Quick.
  • An installed AI helper.

Check it at day 90

The count

  • A reconciled, dated count of every Quick dashboard, measured from the first full count and including every update merged at the day 30, 60 and 90 gates.
  • Each has a reasoned recommendation or a named, aged open decision.
  • If access is incomplete, the count is marked incomplete, with the missing area and a revised date.

The future size

  • The smallest number of dashboards the rationalization shows is needed.
  • Shown separately from any owner-approved target and from the decisions that could still change it. No number is set in advance.

Data use

  • Which data each dashboard uses, and where sensitive data may be exported, recorded for the authorized owners.

Requests

  • Every request from day 61 with one recorded outcome, and delivered work with a dated requester acceptance or rejection.
  • A sample of newly published outputs across the covered channels is matched to request records, with coverage and exceptions shown.
  • If no real request has gone through the way in end to end, that milestone is marked unproven.

The count at day 90, reconciled

First full count, dated, plus added or changed since, equals every Quick dashboard today, split into recommended, waiting with age, and unknown or no access. Values are blank: no number is set in advance. The selected part is emphasized. FIRST FULL COUNT, DATED + ADDED OR CHANGED SINCE = EVERY QUICK DASHBOARD TODAY RECOMMENDED WAITING, WITH AGE UNKNOWN OR NO ACCESS No number is set in advance; the count is measured from the first full count. First full count, dated, plus added or changed since, equals every Quick dashboard today, split into recommended, waiting with age, and unknown or no access. Values are blank: no number is set in advance. The selected part is emphasized. FIRST FULL COUNT, DATED + ADDED OR CHANGED SINCE = EVERY QUICK DASHBOARD TODAY RECOMMENDED WAITING, WITH AGE UNKNOWN OR NO ACCESS No number is set in advance; the count is measured from the first full count.

First full count, dated

  • Every Quick dashboard found at day 30, checked against Quick’s own records, with the date it was taken.
  • The baseline every later number is measured from.

Added or changed since

  • Dashboards built or changed after the first count, picked up at the day 60 and day 90 gates.
  • Nothing built during the project is left outside the count.

Every Quick dashboard today

  • The first count plus the changes since: one number for the whole estate at day 90.
  • Reconciled, so the two sides add up or the gap is shown.

Recommended

  • Dashboards with a recommendation and its evidence: keep, consolidate or harden, or propose retirement.

Waiting, with age

  • Dashboards whose owner has not yet decided, each showing whose call it is and how long it has waited.

Unknown or no access

  • Dashboards the count could not reach, with the missing area and a revised date.
  • Marked, never assumed.

Everything here can be checked on day 90, and anything that cannot be shown is marked missing, not assumed.

What keeps paying back after day 90?

Expected, not measured

  • If records stay current,
    then each request leaves the Register better described, so reuse gets easier.
    We would see the share of requests closed as reuse or update.
  • If owners approve terms captured at intake,
    then definitions build up with the existing dictionary stewards.
    We would see approved definitions linked to requests.
  • If the publish check looks for a record,
    then new assets start with an owner and a review date.
    We would see new assets matched to request records.
  • If intake is the way in,
    then demand becomes visible by domain and urgency.
    We would see a demand view that informs domain order and hiring.

07 / The ask

Three months, on these terms

I wish we already had all this stuff in place, but we’re scrambling. We should be in a good place in like six to 12 months… Maybe like 3 to 6 months. So we’re pushing.Ben

Project Clear Signal: ninety days to rationalize the reporting estate and give every new request one way in, conditional on the endorsements and approvals above.