When an internal tool has a problem, staff usually do one of three things: they tell a colleague, they work around it, or they send a vague message to whoever they know in IT. The developer hears about the problem weeks later, without details, and cannot reproduce it. A simple reporting routine fixes most of this without any new software.
Five fields a report needs
Keep the form short. A shared mailbox, a chat channel with a template or a simple form all work. Ask for these five things:
- What were you trying to do? One sentence, in the person's own words.
- What happened instead? Include the exact message if there was one.
- Where and when? The screen or page, and the approximate time.
- Who is affected? Only you, your team, or everyone.
- A screenshot or example record, if you have one.
Do not ask for browser versions, steps to reproduce or priority. Staff often cannot judge these, and every extra field lowers the number of reports. The triager can add technical details later.
One person triages
Name one person who reads every report on the day it arrives. This is not the person who fixes everything. Their job is to decide what each report is, give it a severity and send it to the right place.
Name a deputy for holidays and write both names where staff will see them. If the tool has an owner, usually the owner is the triager; see who owns an internal tool after its author leaves for how to settle that.
Three severity levels and reply times
Three levels are enough. More levels create arguments about which one applies.
- Stopped: a team cannot do its work or data is being lost or damaged. Reply within one hour during working hours, and start work the same day.
- Hindered: the work can continue, but with a workaround or extra effort. Reply within one working day and agree a fix date within a week.
- Minor: a cosmetic problem or a small annoyance. Reply within three working days and collect these for the monthly review.
The reply time is the time to a first answer from a person, not the time to a fix. A fast, honest answer ("we see it, here is the workaround, the fix is planned for Thursday") keeps trust even when the fix takes longer.
Some reports are not bugs but requests for a change. Move those to a separate list and handle them with a one-page intake rule for change requests.
Tell the reporter what happened
Staff stop reporting when reports disappear. Send a short message at three moments: when the report is received and classified, when a workaround or fix date is known, and when it is fixed. Two sentences each are enough.
If a report is not a bug, say so and explain how the tool is meant to work. That is useful too, and it often shows a gap in training or documentation.
A short monthly overview
Once a month, the triager makes a list of no more than ten lines:
- how many reports arrived, and how many at each severity
- how many were answered within the agreed time
- the two or three problems that repeated
- anything still open for more than a month
Share it with the tool owner and, if you can, with the staff who use the tool. Repeating problems are the best argument for a real fix instead of another workaround. The routine fits naturally into the first 30 days after launching a new internal tool, when reports are most frequent and most useful.
Common mistakes
- A long form. Fewer fields mean more reports.
- No named triager. Reports wait for "someone" and nobody answers.
- Severity set only by the developer. Ask who is affected and what they cannot do.
- Silence after the report. The reporter does not know whether anyone read it.
- Fixing in private. If a fix is made without closing the report, the same problem returns as a new one.
Summary
Ask for five fields, name one triager, use three severity levels with reply times, tell the reporter what happened and read a short list once a month. The setup takes an afternoon. Its cost afterwards is a few minutes a day for the triager, and in return the developer receives problems early, with the details needed to fix them.
Sources
- Common practice for small teams, offered as a practical guide. No client results or market figures are claimed in this article. Adjust the fields, reply times and channels to your own tool and team.