Analytics Request Intake Template
Three documents and three sheets that price every recurring question's payback before it gets built, instead of ranking by how often it is asked.
Free download · No account needed
Repeat Request Analysis
One row per topic that keeps coming back, priced twice
Occurrences and cumulative cost
How many times this exact topic has come up inside the trailing window, and what it has cost so far: average minutes per instance, multiplied by the count, converted to hours.
Build cost, stated honestly
What it actually takes to turn this into a dashboard tile or a saved query: the awkward join, the metric definition nobody has agreed yet, the historical backfill a new dashboard would otherwise lack. Not a round number with no reasoning behind it.
Payback, in weeks
Build cost divided by the monthly hours this topic currently costs to answer by hand. The column the decision actually reads, sorted ascending, independent of occurrence count.
Decision
Build this quarter, or hold and re-price next cycle. Never "we get asked this a lot" as a standalone reason.
Basedash's intake framework sorts incoming requests by urgency and effort, and separately flags a new dashboard as costly because it creates ongoing maintenance, without saying how costly relative to what it saves. Sigma's self-service guide goes one step further: audit the ticket queue, then sort candidates by frequency multiplied by time-to-fulfill, because the top decile by that measure is where self-service returns the most hours. Both stop at consumption. Neither prices what building the fix actually costs, so neither can say whether building it pays off.
So Repeat Request Analysis carries both halves. Every topic that recurs three or more times gets a build-hours estimate next to the monthly hours it currently costs to answer by hand, and dividing the first by the second gives a payback period in weeks. A topic that recurs often but needs an expensive build, because it joins systems with no shared key, can pay back slower than a topic that recurs less but is cheap to build. Ranking by consumption alone cannot see that difference, because it never asks what the fix costs.
Kestrel Software, a fictional B2B SaaS company with a three-person analytics team, logged 340 requests over six months. Nine topics recurred three or more times, consuming 99.75 of 238.58 total ad hoc hours. Priced for payback, only two clear a one-quarter threshold: trial-to-paid conversion and logo churn, an 11-hour combined build reclaiming 7.08 hours a month. Pipeline coverage for board prep recurred seven times, more than five of the other eight, yet has the worst payback of all nine at 27.9 weeks, because its ten-hour build cost outweighs what it saves.
What's in the pack
Intake Policy
The single front door every request goes through, the four fields it needs before it gets worked, and the request types that route data engineering asks elsewhere.
Prioritization Criteria
Routine urgency-and-effort triage for one-off questions, plus the three-step payback gate a new-artifact request has to clear before it gets scheduled.
Self-serve Guidance
The standing list of what already has a self-serve answer, so a repeat of an already-built topic gets a link instead of a new query. A topic blocked on an event that was never instrumented routes to a tracking plan instead.
Request Register
One row per incoming request, with effort, priority and how it was resolved, the raw material every other sheet in the pack is built from.
Repeat Request Analysis
Every topic that recurred three or more times, priced by build cost against monthly hours saved, sorted by the payback period that actually decides what to build.
Capacity View
Monthly ad hoc hours per analyst, and a before-and-after projection once the payback-clearing topics stop being answered by hand.
How to use it
- 1
Open in River, or take it blank
Claim the pack in River and give it your request history, or take the blank documents and sheets and fill them in yourself.
- 2
Send the request log
A shared spreadsheet, exported Slack threads, a ticketing export, or your own memory of what keeps coming up and roughly how long each one takes.
- 3
Get the payback numbers
River fills the register, pulls out every topic that recurred three or more times, and prices each one's build cost against its monthly hours saved.
- 4
Build what clears the bar
Sort by payback rather than by occurrence count, schedule what pays back inside a quarter, and re-price the rest next cycle.
Frequently asked questions
Is this template free?
Yes, no account or card needed to download it. Edit with AI is the optional half, where River reads your request log and runs the payback math itself. Every other pack sits in the template library.
What format are the downloaded files?
Three documents as Word files and three sheets as CSVs, zipped together. The sheets ship with Kestrel Software's illustrative rows in place, so the payback arithmetic is visible before you replace them with your own requests.
How is this different from a normal request tracker?
A tracker logs what came in and how long it took. This pack adds the second half: for anything that recurs, what it costs to build a self-serve answer, and whether that cost pays back inside a quarter. Neither number exists in a plain log.
We have never tracked build cost before. Can we still start?
Yes. The Request Register and the recurring-topic list do not need it. Repeat Request Analysis is the one sheet that needs an honest build-hours estimate per topic, and the first cycle is normally where that estimate gets made for real.
What if a topic recurs but building it never pays back?
It stays an ad hoc answer and gets re-priced next cycle rather than declined outright. Falling build cost, often from a metric getting defined once in a data dictionary, or rising request volume can move it across the line later.
Does this replace writing a real specification for what we build?
No. This pack decides which recurring question is worth building an answer for. Turning that decision into a buildable field-level spec, with what is and is not answerable from the data you have, is a separate step.
Our request log includes customer data. Can we still use this?
Run it inside a private AI workspace, which keeps requester names, topics and effort figures inside your own tenancy rather than a shared one. The register, the payback math and the capacity projection all work exactly as described here.
Find out which repeat question is actually worth building away
Start from the blank documents and sheets, or send River your request log and let it price every recurring topic's payback in weeks.
Edit with AI