Once an internal tool is in use, the requests start. A manager wants one more column, finance wants an export, and someone asks for a button that does what a colleague does by hand. Each request sounds small. Together they become a long list that nobody trusts, and the loudest person wins. A short routine makes the choice visible and fair.
Write down the problem, not the solution
At intake, ask for four things in plain words:
- Who is asking, and which team does the work affected?
- What is the problem today? For example: "I retype the order number into two systems."
- How often does it happen? Daily, weekly, a few times a year.
- What is the workaround now?
Do not accept "add a dropdown here" as the request. Ask what the dropdown should help with. The same problem often has a cheaper fix than the one first proposed. If the request is really a defect, send it to the bug route described in bug reports from staff for an internal tool.
Score each request in three parts
Give every request 1 to 3 points in each part. This takes five minutes per request and is done by the tool owner with the developer.
- Benefit: 3 means many people save real time or an error stops. 1 means one person is mildly happier.
- Cost: 3 means a day or two of work, 2 means about a week, 1 means more than that or needs a new integration.
- Risk: 3 means low risk and easy to undo. 1 means it touches data, permissions or something other systems depend on.
Add the three numbers. A request with 8 or 9 points is a strong candidate; 3 to 5 points is usually a no. The score does not replace judgement. It makes the reasons visible and stops a discussion from starting with "I think".
Put the score and the date in a simple table or shared sheet. One line per request is enough.
Decide once a quarter
Handling requests one by one interrupts the team and favours whoever asks first. Instead, set a fixed quarterly meeting of 30 to 45 minutes with the tool owner, the developer and one or two people who use the tool.
Before the meeting, the owner sorts the list by score and cuts it to the top ten. In the meeting, decide for each one of three outcomes:
- Do it this quarter, with a named person and a rough date.
- Later, with the next review date.
- No, with a reason.
Leave room in the quarter for urgent fixes. A common rule is to plan only about two thirds of the available time. Where a request is large, ask what the smallest useful version is; see how to scope a change after launch for a lighter one-page rule that works for small teams.
Say no with a reason
A no is easier to accept when it has a reason and a way back. Write one or two sentences: "Not this quarter: only two people would use it and it needs a change in the payroll export. Ask again in January if more teams need it."
Tell the requester within a week of the decision, not only at the end of the quarter. People keep asking when a list looks like a black hole, and they stop when they see their request was read and answered.
Keep the list short
Once a quarter, remove requests that nobody has mentioned for six months, and mark duplicates. A list of 15 to 20 open items can be read in ten minutes. A list of 80 cannot, and it is a sign that the intake step is being skipped. If the tool is changing quickly, it also helps to look at the first 30 days after launching a new internal tool, when most requests appear.
Common mistakes
- Taking the solution as the request. You build the wrong thing quickly.
- Scoring without the developer. Cost estimates become guesses.
- Deciding in the hallway. Nobody else sees why a request was chosen.
- Never saying no. The list grows and every item loses meaning.
- Planning every hour. Urgent fixes then push out the planned work.
Summary
Record the problem, score benefit, cost and risk from 1 to 3, decide once a quarter, and answer every request with a yes, a later or a reasoned no. The routine takes about an hour per quarter plus a few minutes per request, and it replaces a list nobody trusts with one the team can defend.
Sources
- Common practice for small teams, offered as a practical guide. No client results or market figures are claimed in this article. Adjust the score, the meeting length and the capacity reserve to your own tool and team.