Triaging Analysis Requests

The Request Queue Problem

Every analyst knows the feeling: Monday morning, the request queue has 14 items. Three are marked urgent. Two are from the VP of Product. One is a request you finished last week that has been reopened with a new question. The rest are a mix of vague asks, well-defined investigations, and one request that is clearly a data engineering task misdirected to you. You cannot do all 14 this week. You cannot do 10. You can probably do 4 well. The difference between a good analyst and a burned-out analyst is not technical skill. It is triage.

Triage is the process of evaluating incoming requests and deciding which to do now, which to defer, which to redirect, and which to decline. It is borrowed from emergency medicine, where the nurse at the intake desk does not treat patients in the order they arrive. She treats them in the order of medical urgency. The analyst's equivalent of medical urgency is not the requester's seniority. It is the combination of business impact, effort required, and data readiness.

Most analysts triage poorly for three reasons:

1. First-in-first-out bias. The analyst works on requests in the order they arrive. This feels fair, but it is not effective. The first request of the week might be a low-impact dashboard tweak, while the fifth is a root-cause analysis that will determine whether the company launches a product feature. FIFO optimizes for perceived fairness, not business value.

2. Loudest-requester bias. The analyst prioritizes requests from the most senior or most persistent stakeholders. This is understandable — saying no to a VP is uncomfortable — but it means the analyst serves the organization's hierarchy rather than its needs. The VP's request to "pull some quick numbers" may be less valuable than the product manager's request to investigate a 15% drop in conversion.

3. No explicit criteria. The analyst prioritizes based on gut feel, which is inconsistent and impossible to explain. When a stakeholder asks "why hasn't my request been done?" the analyst has no defensible answer. "I've been busy" is not a prioritization framework.

The fix is a structured triage rubric that evaluates every request against the same criteria. The rubric makes prioritization transparent, consistent, and communicable. When you tell a stakeholder "your request is queued behind two higher-impact investigations," you are not making an excuse. You are applying a framework.

The Triage Rubric

The triage rubric evaluates every request on three dimensions: impact, effort, and data readiness. Each dimension is scored, and the combined score determines priority.

Dimension 1: Impact (1-5). How much business value does this analysis create? Impact is not the same as the requester's seniority. It is the magnitude of the decision the analysis informs.

• 5 — Strategic: The analysis informs a decision that affects the company's direction: whether to enter a market, whether to launch a product, whether to change pricing. These analyses are rare and high-stakes.
• 4 — Operational: The analysis informs a significant operational decision: whether to increase a marketing budget, whether to roll back a feature change, whether to investigate a data quality issue affecting customer-facing metrics.
• 3 — Tactical: The analysis answers a specific question that helps a team do its work better: which segment to target, whether a campaign performed as expected, what the trend looks like for a specific metric.
• 2 — Informational: The analysis provides context or satisfies curiosity: "what was our revenue last quarter?" "how many users do we have?" These requests are valid but low-impact.
• 1 — Marginal: The analysis has no clear decision attached. "Can you pull some data on X?" with no stated purpose.

Dimension 2: Effort (1-5). How much of your time will this analysis require? Effort is estimated in analyst-hours, not calendar days.

• 1 — Trivial: Under 1 hour. A quick query, a dashboard tweak, a lookup.
• 2 — Small: 1-4 hours. A focused analysis with a clear scope.
• 3 — Medium: 4-16 hours. A multi-step investigation requiring data cleaning, joins, and validation.
• 4 — Large: 16-40 hours. A deep-dive with statistical modeling, stakeholder interviews, and iterative refinement.
• 5 — Very large: 40+ hours. A project, not a request. These should be scoped as projects with milestones, not handled as queue items.

Dimension 3: Data Readiness (1-5). How available and reliable is the data needed for this analysis?

• 1 — Ready: The data exists, is documented, and is known to be accurate. You can start immediately.
• 2 — Mostly ready: The data exists but may need cleaning, joining, or validation. Minor obstacles.
• 3 — Partially ready: Some of the data exists, but key pieces are missing or in a format that requires significant transformation.
• 4 — Mostly missing: The data largely does not exist. You would need to request new data collection, build a pipeline, or find a workaround.
• 5 — Not available: The data does not exist and cannot be obtained in the required timeframe. The analysis is blocked.

Scoring and prioritization. Multiply the three scores to get a composite priority score. A request with impact 5, effort 2, and data readiness 1 scores 10. A request with impact 2, effort 4, and data readiness 3 scores 24. Lower scores are higher priority. The formula rewards high-impact, low-effort, ready-to-go requests and penalizes low-impact, high-effort, blocked requests.

The formula is a starting point, not a final answer. A request with impact 5 and data readiness 5 (blocked) might become high priority if you can unblock the data quickly. A request with impact 1 and effort 1 (trivial) might be done immediately even if the score is not the lowest, because the cost of context-switching is higher than the cost of just doing it. The rubric provides structure; the analyst provides judgment.

Communicating Prioritization Decisions

The triage rubric is only useful if you can communicate its results. Stakeholders do not need to see the formula, but they need to understand why their request is not first in the queue. The communication has three principles:

1. Be transparent about the queue. When a stakeholder submits a request, acknowledge it immediately and give them a realistic timeline. "Thanks for this request. I've added it to the queue. Based on current priorities, I expect to have an initial answer by [date]. If this becomes more urgent, let me know and I will re-evaluate." This sets expectations and gives the stakeholder a chance to escalate if the timeline does not work.

2. Explain the reasoning, not just the ranking. When a stakeholder asks why their request is not done, do not say "it is low priority." Say: "Your request is currently behind two investigations that inform product launch decisions. I expect to get to your request by Friday. If your timeline is tighter, I can either reduce the scope of the current investigations or escalate to see if one of them can be deferred." This gives the stakeholder agency. They can accept the timeline, reduce the scope, or escalate. What they cannot do is pretend the queue does not exist.

3. Offer alternatives. When you cannot do a request, offer something you can do. "I cannot do a full root-cause analysis this week, but I can give you a preliminary look at the trend by Wednesday. If the preliminary data suggests a deeper investigation is needed, we can prioritize it for next week." This is better than a flat no, because it gives the stakeholder partial value and a path to the full answer.

When to decline. Some requests should be declined. Decline when: the request is clearly another team's responsibility (a data engineering task, a data science model), the request has no decision attached and the stakeholder cannot articulate one, or the request requires data that does not exist and cannot be collected. Decline politely and redirect: "This is a pipeline issue, not an analysis issue. I have filed a ticket with the data engineering team and linked you to the tracker. They own the fix."

When to defer. Defer when the request is valid but lower priority than current work. Deferral is not rejection. It is scheduling. "I have added this to the queue for next week. I will start on it Monday." The key is to give a specific date, not "at some point." A deferred request with a date is a commitment. A deferred request without a date is a forgotten request.

When to escalate. Escalate when a stakeholder says a request is urgent but the rubric does not support the urgency. Escalation means involving a shared manager or stakeholder to resolve the conflict. "I have two requests marked urgent: yours and the conversion drop investigation. I cannot do both by Friday. I have asked [manager] to help us decide which takes precedence." This is not passing the buck. It is making the prioritization conflict visible so it can be resolved at the right level.

Triage in Practice: A Monday Morning

Watch the rubric process a realistic request queue.

The queue (8 requests):

1. VP of Sales: "Can you pull the pipeline numbers for my board meeting on Wednesday?" (Impact: 4 — informs a board-level discussion. Effort: 2 — the data exists in the CRM. Data readiness: 1 — the CRM is documented and reliable. Score: 8.)

2. Product Manager: "Conversion dropped 15% after the checkout change. Is it real?" (Impact: 5 — determines whether to roll back a customer-facing change. Effort: 3 — requires segmenting, checking for confounders, and validating the tracking. Data readiness: 2 — the data exists but the recent change means historical comparisons need care. Score: 30.)

3. Marketing Manager: "What was our email open rate last month?" (Impact: 2 — informational. Effort: 1 — a single query. Data readiness: 1 — the data is in the email platform. Score: 2.)

4. Data Engineer: "Can you fix the ETL job that loads the daily sales table?" (Not an analysis request. Redirect to the engineering team.)

5. Executive: "I want to know our customer lifetime value by acquisition channel." (Impact: 4 — informs marketing budget allocation. Effort: 4 — requires defining CLV, joining multiple tables, and making assumptions about future behavior. Data readiness: 3 — the data exists but CLV requires modeling future revenue, which is uncertain. Score: 48.)

6. Customer Support Lead: "Can you analyze support ticket themes?" (Impact: 3 — informs product improvements. Effort: 3 — requires text analysis or manual categorization. Data readiness: 2 — tickets exist but are not categorized. Score: 18.)

7. Product Manager: "Can you build a dashboard showing feature adoption?" (Impact: 3 — informs product decisions. Effort: 4 — requires defining adoption, building the dashboard, and documenting it. Data readiness: 2 — usage data exists but adoption is not defined. Score: 24.)

8. Stakeholder: "Can you look into user engagement?" (Impact: 1 — no decision attached. Effort: unknown — scope is undefined. Data readiness: unknown. Cannot score. Request clarification before triaging.)

The triage:

• Do now (score under 10): Request 3 (email open rate, score 2) — trivial, do it immediately. Request 1 (pipeline numbers, score 8) — high impact, low effort, ready data.
• Do this week (score 10-25): Request 2 (conversion drop, score 30) — highest impact, but the score is higher because of effort and data readiness. Start it Tuesday after delivering the pipeline numbers. Request 6 (support tickets, score 18) — schedule for Thursday.
• Schedule for next week (score 25-50): Request 7 (feature adoption dashboard, score 24) — schedule for next Monday. Request 5 (CLV by channel, score 48) — schedule for next week and scope it as a project with a definition phase before the analysis.
• Redirect: Request 4 (ETL fix) — file a ticket with engineering.
• Request clarification: Request 8 (user engagement) — respond: "Happy to help with this. What decision are you trying to make with engagement data? Are you trying to decide whether to invest in a specific feature, or understand a trend?"

The communication: Send a brief update to the stakeholders whose requests are deferred: "I have triaged the current queue. I will complete the email open rate and pipeline numbers today. I am starting the conversion investigation Tuesday. The support ticket analysis is scheduled for Thursday. The feature adoption dashboard and CLV analysis are scheduled for next week. If any of these timelines do not work, let me know and I will re-evaluate."

This is what triage looks like in practice. Every request is evaluated, every stakeholder gets a timeline, and the analyst's week is structured by business value, not by arrival order.