Work Intake for Planning and Analytics Teams

From WFM Labs

Work intake is the practice by which a planning, forecasting or analytics team receives, records, classifies and schedules the requests made of it. Most such teams have no single point of intake: asks arrive by email, chat, meetings and hallway conversation, and the team's capacity is spent on whoever asked last rather than on what matters most. This article describes the failure that produces, firefighting, and an intake design that makes the allocation of the team's hours visible and deliberate. The design treats team time the way a workforce function already treats frontline time: as a budget with a measurable demand, a measurable supply and an explicit queue.

Four channels feed one capture step. Real asks are clarified, classified and triaged, then assigned to one owner within a capped active load; overflow waits in a ranked backlog, large items become program candidates, and repeat fires loop back to a root-cause fix.

The problem

Asks reach a central planning team through every channel the organization uses: email in Outlook, messages in a chat tool such as Zoom Team Chat, Zoom meetings, phone calls and conversations in the corridor. None of them passes a common point. Asks are lost, duplicated and re-asked, and the only record of what was promised is in individual inboxes and memories.

The load is measurable. Microsoft's telemetry for 2025 found the average worker in its suite interrupted every two minutes by a meeting, email or notification, receiving 117 emails and 153 chat messages a day, with 57% of meetings held as ad hoc calls without a calendar invitation.[1] Interruption has a cost beyond the time it takes: in a controlled study, interrupted workers finished tasks faster but with significantly more stress, frustration and time pressure.[2] At organizational scale, time is managed far less rigorously than capital: a study of 17 large companies found time budgets largely unmanaged, and in one of them a single weekly executive meeting consumed 300,000 hours a year across the people who supported it.[3]

Generative tools are adding to the volume. Meeting summaries and drafted notes circulate more content without necessarily producing more decisions. A 2025 survey found 40% of desk workers had received low-substance AI-generated work in the previous month, and recipients spent close to two hours dealing with each instance.[4] The authors' remedy is a norm for how such output is used, which an intake design can supply: notes and summaries open with the decisions made, the asks with their owners and the dates, and everything else is optional reading.

Firefighting

Bohn described firefighting as an organizational syndrome rather than a matter of individual temperament. It is present when there are chronically more problems than people have time to solve, when problems are patched rather than fixed, when the same problems recur, and when urgency routinely overrides importance.[5] Each patch is a reasonable local decision; together they consume the capacity that would remove the causes.

Repenning and Sterman explain why the pattern persists. Under pressure, people work harder rather than improve the way they work; the improvement that would relieve the pressure needs time that the pressure has consumed, and the credit for problems that never happen is invisible. The result is a capability trap in which a team becomes steadily busier and steadily less able.[6] A planning team caught in it spends its days answering and has no hours left to improve forecasts, models or tooling, which is the work that would reduce the asks.

Run the business and change the business

The design separates three kinds of work.

Work type Test Examples In the tracker?
BAU (run the business) Standard outputs on their normal cadence, with no new design The regular forecast cycle, intraday management, standard reports No
One-off A bounded request outside the standard outputs A forecast variant for a new scenario; a run-off analysis for a site closure Yes
Project Work that serves a named project or strategic initiative Tasks inside a technology or integration program Yes, tagged with the project

Business-as-usual work stays out of the tracker, because logging every routine output would bury the signal. It stays in the capacity budget through a BAU register: one row per recurring output, with its cadence, hours per run and owner. Without the register the team cannot say how many hours are actually left for one-offs and projects, and every limit set later is a guess.

Three boundary rules keep the categories clean. When a BAU process breaks or needs redesign, the fix is a one-off. A one-off that grows beyond about a week of effort becomes a candidate project, with a sponsor, a scope and a business case. Notices and copies sent for information are never logged.

Classification and priority

Every one-off or project ask carries four tags. Source records whose demand it is: the team's own leadership line (LL), partner operations leaders (PO), another function on behalf of a named client or program (XF), another function with nothing named (XO), or the team itself (IN). Urgency runs from U1 (live customer or service impact today) through U2 (a hard date within five business days) and U3 (a later date) to U4 (no date). Alignment records what the ask serves: A1 a named priority, A2 keeping operations running, A3 no stated purpose. Size is a band: under an hour, under a day, one to five days, more than five days.

Priority follows from urgency and alignment alone:

Priority Rule
P1 Any U1, or A1 with U2
P2 A1 with U3 or U4, or A2 with U2
P3 A2 with U3 or U4
P4 Any A3 that is not U1

Source deliberately does not change priority; it shows whose demand is consuming capacity. Two exceptions route trade-offs to the person who can make them. A medium or large ask from the leadership line gets a same-day reply naming what it would displace. So does an ask due this week, from the leadership line or from partner operations leaders, with no stated purpose, which the rule would otherwise place at P4 and which would in practice be worked anyway.

Triage then gives each ask one of six outcomes: do now (P1, or work quicker to finish than to record), assign an owner and date, plan it into a later week, park it with a review date, redirect it to an existing report or the right owner, or decline it once the line leader has agreed.

Capture and clarification

Capture has to cost seconds, or it decays. Asks stay in the channel where they arrived, and only a one-line version moves into the tracker. In practice that means tagging emails that hold an ask with an Outlook category, saving chat messages, jotting hallway asks in one line, and ending each meeting with a short spoken recap of asks, owners and dates. At the end of the day each person pastes the flagged material into an approved AI assistant with a fixed prompt, which drafts tracker rows in the tracker's column order; the person checks them in under a minute and pastes them in. A SharePoint list serves well as the tracker: choice columns enforce the codes, a calculated column computes priority, saved views give each person their own work, and its grid view accepts pasted rows. Any list or spreadsheet with validated columns will do.

Most asks arrive spoken and under-specified. Any row that lacks a deliverable, a date or a named requester gets a confirm-back within one business day, answering five questions: what exactly is handed over, who receives it and what decision it feeds, when it is needed and what happens if it is late, what good enough looks like, and who owns it on the team. Silence counts as confirmation for small asks; medium and large asks need an explicit yes before work starts.

Work-in-progress limits and Little's Law

Every ask gets one named owner, and each person carries a capped number of active items. Beyond the cap, new work waits in a ranked backlog or something else comes off the person's plate, by an explicit swap.

The cap is not arbitrary. Little's Law states that, in a stable system, the average number of items in it equals the arrival rate multiplied by the average time each spends there.[7] Rearranged for an intake tracker, the implied lead time is the number of open items divided by the completion rate. If asks arrive faster than they are finished, the open pile grows by the difference every week, and the lead time for everything in it grows with it. That is firefighting expressed as a queue. The lead time measured on closed items is the natural check, but it counts only finished items, so it runs low whenever work is accumulating; read the two together with the list of backlog items 30 or more days old.

The same arithmetic sizes the cap. A person with H discretionary hours a week, spread across W active items, gives each item H/W hours a week, so an item needing h hours takes h·W/H weeks. To finish a typical item within T weeks, W must not exceed H·T/h. A person with 12 discretionary hours a week, finishing a four-hour ask within a week, can hold three active items; a cap of five promises a lead time the hours cannot deliver.

Capacity as a budget

Discretionary capacity is what remains of the team's paid hours after the BAU register, standing meetings, protected improvement time, other fixed commitments and the measured firefighting load:

discretionary hours = total − BAU − meetings − protected − other − firefighting

In a synthetic team of 6 analysts and leads at 40 hours a week each, the 240 weekly hours net down to 96.9 discretionary hours (40% of the total), while plannable asks (leaving out urgent firefights, already netted from capacity, and work large enough to be a program) arrived at about 63.9 hours a week, 66% of what was available. On paper there is room. Yet only about 26.9 plannable hours a week were completed, and asks arrived at 16.2 a week against 12.5 finished, so the open pile grew by about 3.8 items a week. The data cannot say whether the budget is missing time it should count, such as unlogged ad hoc work, or whether too much is open at once; both point to honest logging and a lower work cap. Hours and counts can disagree, and the readout reports both. Once demand passes the discretionary hours, something must be parked, redirected or declined every week, and the only open question is whether that is decided deliberately. The same team's per-person caps, by the rule above, came out at 3.5 to 4.3 active items rather than a uniform five. These are properties of the illustration, not benchmarks.

Protected time, typically a half-day per person per week for improvement that triage cannot consume, is the mechanism for escaping the capability trap. It should break only for live customer impact, and it grows as the reactive load falls.

Repeat fires

A repeat is an ask the team has answered before. The tracker links each repeat to the earlier item, and a simple rule converts patching into fixing: three occurrences of the same ask within 30 days open a root-cause one-off, owned by the lane lead, whose deliverable removes the need for the ask, such as a standard report, a self-service view or a corrected source. In the synthetic team, one recurring ask (reconciling two headcount figures) reached 5 occurrences in 30 days and consumed about 6 hours, each instance a patch. This is the step Bohn and Repenning and Sterman both identify as the way out: spending scarce capacity on the cause rather than the symptom.

Rhythm

The design runs on a short cycle. Each person starts the day from their own view of active work and ends it with the capture paste, about 15 minutes in total. A fixed daily triage of about 15 minutes assigns owners, lanes and outcomes and sends confirm-backs. A weekly 30-minute capacity review ranks the backlog, makes swaps and decides what slips and who is told. A monthly readout to the leadership line reports volume, sources, priorities, the program candidates and the trade-offs that need a decision. The readout is computed from a weekly export of the tracker, so its counts are facts rather than impressions.

Measuring whether it works

At 90 days the design should show:

  • Capture coverage: tracker rows set against the volume of email, chat and meetings, showing whether asks are being recorded rather than worked invisibly
  • Firefighting share: the proportion of new asks and hours that are U1, falling
  • Protected time kept: the share of protected half-days actually spent on improvement
  • Lead time: implied and measured lead time, converging and falling
  • Repeats: repeat chains reaching the trigger, and repeat asks as a share of intake, both falling as root-cause work lands
  • Demand against capacity: plannable demand hours against discretionary hours, and against the hours actually completed, with any gap closed by explicit decisions

Failure modes

  • Capture decays. The design depends on a few minutes a day from everyone. Coverage should be measured, and requesters can make capture nearly automatic by opening asks with "Ask:" and a date.
  • Hours logging is abandoned. Logged actual hours rarely survive the first month. Size-band defaults (half an hour, half a day, a few days) carry the budget, with actuals asked only for medium and large work and for urgent firefights.
  • The tracker becomes a second inbox. Logging without triage only moves the pile. Daily triage and the active cap are what change the allocation.
  • Urgent, unaligned asks from leaders. They will be worked whatever the rule says; routing them to an explicit same-day trade-off keeps them visible.
  • Invisible firefighting. Work done immediately because it is urgent must still be logged afterwards, or the firefighting load, the thing the design exists to measure, disappears from the data.

See also

References

  1. ↑ Microsoft WorkLab (2025). "Breaking Down the Infinite Workday". Work Trend Index special report, 17 June 2025.
  2. ↑ Mark, G., Gudith, D., & Klocke, U. (2008). "The cost of interrupted work: more speed and stress". Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI 2008), 107–110.
  3. ↑ Mankins, M., Brahm, C., & Caimi, G. (2014). "Your Scarcest Resource". Harvard Business Review, May 2014. Summarised by Bain & Company, "The 300,000-hour meeting".
  4. ↑ Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., & Hancock, J. T. (2025). "AI-Generated 'Workslop' Is Destroying Productivity". Harvard Business Review, September 2025. Survey of 1,004 US desk workers by BetterUp Labs and the Stanford Social Media Lab.
  5. ↑ Bohn, R. (2000). "Stop Fighting Fires". Harvard Business Review 78(4), July–August 2000.
  6. ↑ Repenning, N. P., & Sterman, J. D. (2001). "Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement". California Management Review 43(4), 64–88. doi:10.2307/41166101.
  7. ↑ Little, J. D. C. (1961). "A Proof for the Queuing Formula: L = λW". Operations Research 9(3), 383–387.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Work_Intake_for_Planning_and_Analytics_Teams&oldid=5353"