How to build a report request queue

What matters here

• A report queue is four parts: the decision behind the request, a duplicate check, prioritisation against capacity, and a self-serve route.
• Ask what decision this informs. People request columns; the decision is what tells you whether a sentence would do.
• A large share of requests already have an answer. Search existing reports at submission, not after the work starts.
• Ask when the decision is made, not when the requester wants it. Those are different dates and only one is real.
• Track which requests repeat. Three of the same is a dashboard, and that is how a data team stops being a helpdesk.
• Record whether the answer changed the decision. It is uncomfortable and it is the only measure of whether the work mattered.

Who this is for

You run a data or analytics team that has become a request queue. What you want is fewer requests, better ones, and an argument for headcount that is not just a list of tickets.

How it works in practice

What happens between somebody wanting a number and the data team doing anything.

1. 1

   The form asks what decision this informs

   Before it asks for columns. People request a spreadsheet; the decision underneath is usually smaller than the request.

2. 2

   It searches what already exists

   Against registered dashboards and open requests, at submission, so a third of these close before anyone starts work.

3. 3

   It asks when the decision is made

   Not when the report is wanted. Those are different dates and only the first one is real.

4. 4

   It gets scored and ranked against capacity

   With the line drawn visibly, so the conversation is about how much the team can do rather than about individual requests.

5. 5

   Waiting-on-the-requester is timed separately

   Because a meaningful share of what looks like data team delay is a clarification nobody answered.

6. 6

   Repeats get promoted to self-serve

   Three requests on one topic becomes a dashboard, and everyone who ever asked is told it now exists.

1. 1

   Ask what they are deciding

   The one field that changes the whole conversation.

   Copy

   In this Helix project, build me a report request queue for our data team.
   
   The form asks for the usual things: requester, team, what they want, and
   any filters or breakdowns.
   
   But lead with a different question, and make it required: what decision
   will this inform, and what would you do differently depending on the
   answer.
   
   People ask for a spreadsheet with six columns. Once you know they are
   deciding whether to renew a contract, you can often answer it in a
   sentence, or point at a dashboard built last quarter, or realise the
   six columns would not actually have told them.
   
   Then ask for the date the decision is made, not the date they want the
   report. Those are different, and only the first one is real. Ask for the
   difference explicitly if the two dates are far apart.
   
   And ask how they will use it: a one-off answer, something they need
   monthly, or something they want to look at whenever. That answer decides
   whether this is a query or a dashboard, and it is much cheaper to know now.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. The decision field is the highest-value question in this app. It repeatedly turns a two-day report into a two-minute answer.

2. 2

   Check whether it already exists

   Because a lot of the queue is search failure.

   Copy

   Before anything is triaged, search what we already have.
   
   Let me register existing reports and dashboards with their name,
   description, what questions they answer, the owner and a link. Then on
   submission, search those against the request text and the decision, and
   show the requester likely matches immediately.
   
   Let them close their own request by saying one of those answered it, and
   record that. That count is the size of the search problem, and it is
   usually large enough to be worth fixing separately.
   
   Also check open requests, so two people asking for the same thing in the
   same week become one piece of work with two people notified.

3. 3

   Prioritise against what the team can do

   And show the line.

   Copy

   Score each request on the size of the decision it informs, the real
   deadline, and the estimated effort, with the weights in a config file I
   can edit. Effort is estimated by the team, not the requester.
   
   Then rank against capacity: who is available, for how long, and what they
   are already committed to. Draw a line where capacity runs out and show
   what falls below it.
   
   Do not hide the below-the-line list. A queue with no capacity model just
   re-sorts a list longer than the team can deliver, and everybody stays
   disappointed without understanding why.
   
   Let a leader override the order with a reason, and log every override.
   
   Track time in each status, and report time waiting on the requester
   separately. A meaningful share of what looks like data team delay is a
   request sitting with the person who raised it waiting for a clarification.

4. 4

   Turn repeats into self-serve

   The only thing that actually shrinks the queue.

   Copy

   Tag every request with a topic, and report which topics recur.
   
   Three requests for the same thing is a dashboard. Make that an explicit
   action: promote a repeated request into a self-serve report, register it
   in the existing-reports list, and notify everyone who has ever asked for
   that topic that it now exists.
   
   This is the only mechanism that reduces the queue rather than processing
   it faster, and without it a data team stays a helpdesk regardless of how
   efficient it gets.
   
   Then two reports. One for the team: requests by topic, by requesting team,
   turnaround, and the proportion answered by pointing at something that
   already existed. And one that is uncomfortable: for delivered requests,
   did the answer change the decision. Ask the requester a fortnight later.
   A high proportion of no is the most useful thing this app will ever tell
   you.

   Worth knowing. The did-it-change-the-decision question is awkward to ask and it is the only honest measure of whether the work mattered.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Looker>. Read the existing reports and dashboards, so a submission can be
   matched against them immediately.
   
   <Okta>. Resolve requesters, their teams and the analyst group you assign
   to, so none of it depends on a list somebody maintains.
   
   <Slack>. Tell everyone who ever asked for a topic when it becomes a self-
   serve dashboard.
   
   <Jira>. Push accepted requests to wherever the team actually works, rather
   than a second queue.
   
   <Snowflake>. Check whether the data a request needs actually exists before
   it is scheduled.
   
   <Google Sheets>. Deliver one-off answers where requesters will actually
   use them.
   
   <Notion>. Publish the self-serve reports so a repeated request becomes a
   link.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Requests reference commercially sensitive decisions, so set Access Control before sharing: requesters see their own, the data team sees the queue.

What it connects to

Half the value is telling somebody the answer already exists, which means seeing what already exists.

• Looker

  Read the existing reports and dashboards, so a submission can be matched against them immediately.

• Okta

  Resolve requesters, their teams and the analyst group you assign to, so none of it depends on a list somebody maintains.

• Slack

  Tell everyone who ever asked for a topic when it becomes a self-serve dashboard.

• Jira

  Push accepted requests to wherever the team actually works, rather than a second queue.

• Snowflake

  Check whether the data a request needs actually exists before it is scheduled.

• Google Sheets

  Deliver one-off answers where requesters will actually use them.

• Notion

  Publish the self-serve reports so a repeated request becomes a link.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides