Triaging Demand As A Business Analytics Services Provider Our queue held two hundred and sixty requests. The oldest was nineteen months. We closed about twelve a month and received about thirty. That arithmetic has only one ending. Here is how we restructured the intake, written from inside a team that functions as a Business Analytics Services Provider to eleven internal departments. A queue that only grows is a design fault Not a capacity problem. Our instinct, like that of every Business Analytics Services Provider under pressure, was to ask for more analysts. Two more analysts would have moved us from twelve a month to perhaps eighteen, against thirty arriving. The intake was the problem. We were accepting every request as equally valid work and then prioritising among them, which is sorting rather than deciding. Sort requests into four kinds They need completely different responses. A question, which wants a number once. A monitor, which wants to be told when something changes. An investigation, which wants to understand why. And a product, which wants a lasting capability other people will use. About sixty per cent of our queue were questions. We had been treating them as products, which is why each took three weeks. Answer questions as questions The change that cleared the backlog. A question gets an answer, in writing, within two working days. Not a dashboard, not a model, not a reusable asset. A number, the definition behind it, and a note on what it does not cover. Our queue halved in seven weeks. Most of those requests had never wanted a dashboard, and we had been building one because that was what our process produced. Ask what happens if the answer is surprising The filter that removes unnecessary work. If nothing changes regardless of the result, the request is curiosity. Curiosity is legitimate and it is not urgent, and saying so openly is better than quietly deprioritising it for nineteen months. About one request in six falls here. We answer them in a monthly batch and nobody has complained, because they were told. Publish the queue Uncomfortable and effective. Every department can see every request, its kind, its age, and its position. Our own prioritisation reasoning is attached. Two things happened. Departments started withdrawing their own stale requests, and the private escalations to my manager stopped almost entirely, because the trade-offs were visible rather than suspected. Make the repeated questions self serve The compounding work. We logged every question for a quarter and found that forty one per cent were variations of nine underlying questions. Those nine became a small set of parameterised views. That removed about a third of our incoming volume permanently, which no amount of working faster would have achieved. Protect time for the preparation work The work that has no requester. Reconciliation, matching logic, late arriving records, and the AI data preparation steps feeding anything downstream. Nobody raises a ticket for it and everything degrades without it. We ring fence about a quarter of our capacity for it. Our previous arrangement allocated it whatever was left, which was nothing, for about fourteen months. Say no with a reason and an alternative The practice that keeps relationships intact. We decline roughly one request in eight. Each declined request gets a written reason and, wherever possible, a suggestion of what would be a better use of the same effort. Declining with a reason has cost us no goodwill. Accepting and then not delivering for nineteen months cost us a great deal. Keep an eye on what the work costs to run Easily forgotten inside an internal team. Every monitor we build runs forever. Every scheduled job consumes something. Our Cloud Computing Services bill for the analytical estate grew steadily while our headcount did not. We now attach an estimated running cost to anything recurring, and we retire monitors nobody has acted on in six months. Eleven were retired in the first review. Review what was actually used The loop that prevents the next backlog. Six months after delivery, we check whether the thing is opened and whether any decision referenced it. About a quarter are not. Those get retired, and the pattern in them tells us which kinds of request to challenge harder at intake, which is how a Business Analytics Services Provider gets better rather than merely busier. What our intake process does ● Classifies every request as question, monitor, investigation, or product. ● Answers questions in two days, in writing, without building anything. ● Asks what changes if the answer is surprising. ● Publishes the full queue with reasoning attached. ● Converts repeated questions into parameterised self serve views. ● Ring fences a quarter of capacity for preparation work. ● Declines about one in eight, with a reason and an alternative. ● Attaches an estimated running cost to anything recurring. ● Reviews usage six months after delivery and retires what is unused. Common questions Does publishing the queue cause arguments? Fewer than hiding it did. The arguments move from suspicion about favouritism to discussion of actual trade-offs. How do you handle urgent requests? A small reserved capacity, with urgency defined by a date something depends on rather than by who is asking. Is two days realistic for a question? For a question, yes, once you stop building a product in response to it. That reframing was the entire improvement. What about requests from senior people? Same process, published queue. A Business Analytics Services Provider that reorders silently for seniority loses the trust of everybody else quickly. Does this apply to an external firm? It applies more. An external Business Analytics Services Provider is paid per piece of work and has less incentive to challenge whether the work should exist. What about the running cost of what you build? Attach an estimate and review it. Our Cloud Computing Services bill for the analytical estate grew for two years purely through monitors nobody retired. How do you justify the preparation time? By showing what breaks without it. We let it slide for fourteen months and the resulting reconciliation work was visible to everybody. Where we are now A queue of thirty one, questions answered in two days, nine self serve views covering four tenths of former demand, and a quarter of capacity protected for the invisible work. We did not hire anybody. We stopped turning every question into a project, which turned out to be the whole of the backlog.