A week after an internal tool goes live, the requests start. One user wants another column, another wants the form shortened, a manager asks for a report "like the old sheet," and someone mentions in the corridor that the export is wrong. Without a rule, the developer or the team lead decides in the moment, usually in favour of whoever spoke last.
This article is for a department lead who owns a tool that is already in use. It describes a short intake rule that fits on one page. It is about the queue of requests, not about the wider question of helping people adopt new technology, which we cover in change management for technology adoption.
Why a rule is needed
Requests after launch are a healthy sign: people use the tool and see how it could be better. The trouble is not the number of requests but the way they are handled.
- Requests live in five places (chat, email, meetings, sticky notes, memory), so none of them is complete.
- Urgent-sounding items push out important ones.
- The person who asks gets no answer, asks again, and trust in the tool drops.
- Small changes made on the spot add up to a tool nobody can describe.
A rule does not slow work down. It makes the decision visible and repeatable.
Rule 1: one queue, one owner
Pick one place where requests are recorded. A shared list, a simple board or a form that feeds a spreadsheet is enough. What matters is that it is the only place. Tell the team: "If it is not in the queue, it does not exist."
Name one owner of the queue. This is usually the person who owns the tool (see our note on who owns an internal tool). The owner does not have to do the work, but they decide the order and give the answers. Name a deputy for holidays.
Rule 2: five fields for every request
Before a request is discussed, it is written down in five fields. If the requester cannot fill them in, the owner helps in a two-minute conversation.
- What happens today. The situation in one sentence, for example "Saving an order takes six clicks."
- What is needed. The change, stated as an outcome rather than a design.
- Who and how often. How many people are affected and how often a week.
- What it costs today. An honest estimate of lost time or errors, even if rough.
- Who asked and when. So that you can answer them.
Five fields take a few minutes and filter out a surprising number of requests. Many turn out to be duplicates, questions about how to use the tool, or wishes that disappear when the requester has to describe the cost.
Rule 3: sort into three groups
Every request goes into one of three groups on the day it arrives.
| Group | What belongs here | When it is handled |
|---|---|---|
| Defect | The tool does not do what it was meant to do, or blocks daily work | Immediately, or within a few working days |
| Improvement | The tool works, but could save time or reduce errors | In the quarterly batch |
| Not now | A wish that does not fit the tool's purpose or has no clear cost | Answered with a reason and kept in the list for review |
Defects that block work are fixed at once because waiting costs more than the fix. Everything else waits for a fixed date. The quarterly batch is the important part: it lets the developer plan, gives users a date to expect, and stops the tool from changing every week.
Rule 4: rank the batch by effect
Once a quarter, the owner and one or two regular users go through the improvement list. Rank by a simple product: people affected, times by how often, times by minutes saved or errors avoided. You do not need exact numbers. Rough categories such as small, medium and large work well enough.
Then add the effort, stated by the developer in the same rough categories. Large effect with small effort goes first. Large effort with small effect usually moves to "Not now."
Resist the pull of the loudest voice. A request from a senior person is not automatically more valuable, but it deserves a clear explanation if it is placed low.
Rule 5: close the loop
Every request gets an answer within a week, even if the answer is "in the batch, planned for the next review" or "no, because the tool is not meant for this." Send the answer to the person who asked.
When a change is released, tell the requesters, and tell all users in one or two lines what changed. A short change note in the same place every time is enough. Users who see their request come back as a finished change keep sending good ones.
A short example
Imagine a sales support team using a new internal tool for quotes. In the first month the queue holds nine requests. Two are defects: a quote cannot be saved when the customer name contains a special character, and the print view cuts off the last line. Both are fixed within the week. Four are improvements, for example a default value for the delivery term and a filter by status. They go into the first quarterly batch, and the owner ranks them with two users. Two are duplicates of the same wish for a monthly report, which the owner merges and answers in one message. One asks the tool to also manage invoices, which is outside its purpose and is answered with a clear no.
Nothing here is complicated. What changes is that every person who asked knows where their request stands.
What to avoid
- Several channels. If requests are accepted in chat and in the queue, the queue becomes optional.
- Quiet small fixes. A change made "just this once" is a change nobody reviewed.
- Treating every request as urgent. If everything is urgent, the defect group has lost its meaning. Keep it for work that is actually blocked.
- Never saying no. An unanswered request is worse than a polite refusal.
- A batch that keeps slipping. If the quarterly date moves repeatedly, users go back to asking for things on the spot.
What to do this week
Choose the single place for requests and tell the team. Write the five fields at the top of it. Move the requests you already remember into it, sort them into the three groups, and put the date of the first batch review into the calendar. Our guide to the first 30 days after launching a new internal tool shows where this fits in the first weeks.
Sources
- Our related articles linked above.
- The groups, fields and quarterly rhythm are a general working approach, not a standard; adapt the timing and thresholds to the size of your team and the volume of requests.