The expense form rejects any amount with a comma. The stock spreadsheet macro stopped working after an update. The internal order tool shows yesterday's prices. Each problem is reported, usually in a chat message, usually to whoever happens to be online. A week later nobody remembers who said what, and the people who reported it have learned that reporting does not help.
Internal tools rarely get the care that customer-facing products get, yet a company runs on them every day. A small triage routine fixes most of this without new software.
What triage means here
Triage is a quick decision about each reported problem: how serious is it, who looks at it, and by when. It is not the fix itself. The goal is that every report gets an answer within a known time, even if the answer is "not now".
One place to report
Pick one place where bugs are reported: a shared mailbox, a form, or a channel with a pinned template. The place matters less than the rule that a report outside it is gently redirected. If you already run a shared mailbox as a ticket queue, the same queue can take tool bugs.
Ask for four things in every report: what the person tried to do, what happened, what they expected, and how much work it blocks. A screenshot helps. Do not ask for more; long forms stop reports.
Three severity levels
Use three levels and define them by effect on work, not by technical cause:
| Severity | Meaning | Example |
|---|---|---|
| 1 – Blocks work | People cannot do a core task and no workaround exists | Nobody can create invoices |
| 2 – Slows work | The task can be done, but with a workaround or extra effort | Prices must be copied by hand |
| 3 – Annoys | Cosmetic or rare, work is not affected | A button label is misspelled |
Resist a fourth or fifth level. When people argue between "high" and "critical", the scale has too many steps. If a report is on the border, take the higher level and revisit after the first look.
One owner, one response time
Each bug gets one named person as owner. This person does not have to fix it, but must make sure it moves. A team or a mailbox is not an owner.
Agree on response times for each level and write them down:
- Severity 1: first response within two working hours; work continues until there is a fix or a workaround.
- Severity 2: first response within one working day; a plan or date within a week.
- Severity 3: acknowledged within a week; handled in the weekly list.
"Response" means the reporter hears something: who has it, what the next step is, and when to expect news. It does not mean the bug is fixed. Pick times your team can actually meet; a promise that is broken every week is worse than a slower, honest one.
Who triages
In a small company, one person does the first sorting, ideally the one who knows the tools best, with a named deputy for holidays. Triage takes minutes per report. The triager checks that the report is clear, sets the severity, assigns the owner, and replies to the reporter. If it is a duplicate, link it to the existing one and tell the reporter.
Decide in advance who may change a severity. Usually the triager does, and the reporter can ask for a second look with a reason.
The weekly list
Once a week, for about 20 minutes, the triager and the tool owners look at the open list. Keep it short and fixed:
- Any severity 1 or 2 bug past its response time? Decide who acts today.
- Which severity 3 bugs can be done together in one small batch?
- Which bugs are older than a month? Fix, schedule or close them with an honest "we will not fix this".
- Is the same tool producing many bugs? That is a signal for a bigger repair or a replacement, and belongs in a proper requirements discussion rather than in more patches.
Close the list by sending reporters a short note about what happened to their report. Even "we decided not to fix this, here is the workaround" keeps trust.
Workarounds and communication
For severity 1 and 2, the first useful thing is often a workaround, not a fix. Write it down in two lines and send it to the people affected. A known workaround turns an emergency into a scheduled repair.
When a bug affects many people, tell them once, in the channel they read, and again when it is resolved. Do not make each person ask separately.
Keeping count
You do not need a dashboard. Once a month, note three numbers: bugs reported, bugs closed, and bugs open longer than a month. If the third number keeps growing, you have a capacity problem, not a triage problem, and the conversation should be about time or budget for the tool.
Common mistakes
- Several places to report, so no one has the full list.
- Severity defined by how loud the reporter is rather than by effect on work.
- No owner, so everyone assumes someone else has it.
- Response times that are never met.
- Closing bugs silently, so reporters stop reporting.
- Letting severity 3 bugs pile up until the tool feels broken as a whole.
- Treating every bug as an emergency, which exhausts the team.
Summary
Triage for internal tools can be light: one place to report, three severity levels defined by effect on work, one named owner and an agreed response time for each level, and a 20-minute weekly list. The result is not fewer bugs but fewer forgotten ones, and colleagues who keep reporting because they see something happen.
Sources
- Our related articles linked above.
- The severity levels, response times and weekly rhythm are working practices for small and mid-sized companies, not a formal standard; adjust them to your size. No client results or market figures are claimed in this article.