When an internal tool is new, questions arrive everywhere: in chat, by email, at the coffee machine and straight to the developer. The developer is interrupted all day, and users never know whom to ask. The cure is not a help desk. It is a simple first line of support that handles most questions and passes on only the rest.
Who answers
Choose one person who answers first, and one backup. This should be someone who uses the tool daily and knows the work around it, not necessarily a technical person. Give them a clear message to staff: "Questions about the tool go to this person, in this one place."
Agree on a realistic reply time, for example the same working day. A fast "I have seen it, I will look at it today" is already half of good support.
Keep one place for questions: a shared mailbox, a chat channel or a simple form. If you already have a one-page intake rule for change requests, use the same entry point and separate the two types of message by a label: "problem" and "request".
What to ask the user
Most unclear messages ("it does not work") can be turned into a useful report with three questions:
- What were you trying to do? The goal, not the click path.
- Where exactly did it happen? Which screen, which record, which button.
- Since when, and has it ever worked? Today only, since the last update, or always.
Add two things if the person can provide them: a screenshot with the message visible and the name or number of the record concerned. Do not ask for more. Long forms make people give up and ask a colleague instead.
First answer or escalate
The first line should solve what it can. Typical cases are a forgotten password, a missing permission, a question about how to do something and a mistake in data entered by the user. For these, the answer list below is usually enough.
Escalate when at least one of these is true:
- Data is lost, wrong or visible to someone who should not see it.
- The tool is down or a whole team cannot work.
- The same problem was reported by three people within a week.
- You cannot reproduce it or explain it after fifteen minutes.
- The fix needs a change in the tool, not in how it is used.
When you escalate, pass on the three answers, the screenshot, what you already tried and who is waiting. The developer should not have to ask the same questions again. For the next step, bug triage for internal tools describes how to sort what arrives.
Always tell the user that the case has been passed on and when to expect news. Silence is the most common reason people stop reporting problems.
Keep a shared answer list
Every solved question is worth writing down once. Keep a single shared document or page with this structure:
| Question as users ask it | Short answer | Who solved it | Date |
|---|---|---|---|
| I cannot see last month's orders | Check the date filter; default is 30 days | First line | 3 March |
| The export is empty | Select at least one status first | First line | 9 March |
Write the question in the words users really use, not in technical terms. Then the answer is easy to find. This is the same idea as an internal FAQ that people actually use, only fed directly by real cases.
Add to the list within a day of solving a case. Later it will not happen.
Make the tool help the first line
Support is easier when the tool leaves traces. If you can see who did what and when, many questions are answered in a minute. What to log in a small internal tool lists the few events that matter. Also keep two pages of documentation where the first line can find them, and tell staff about changes with short release notes, so that a changed button does not become ten questions.
Monthly review
Once a month, take fifteen minutes and look at the list and the escalated cases:
- Which questions repeat? Move them into the tool as a hint, a better label or a fix.
- Which answers are outdated? Remove or correct them.
- Which escalations could the first line have solved? Add the answer.
- Is the reply time kept? If not, is the load too high for one person?
A repeated question is a signal about the tool, not about the users.
Common mistakes
- Everyone asks the developer. Interruptions grow and the first line never learns.
- No backup. Support stops during holidays and illness.
- Answers only in chat. Nobody finds them next month.
- Escalating without details. The developer starts from zero.
- Never cleaning the list. Old answers mislead more than no answer.
How to start this week
- Name the first-line person and the backup.
- Choose the one place for questions and tell everyone.
- Write the three questions in the place where messages arrive.
- Copy the five escalation rules and adjust them to your tool.
- Create the answer list with the first five questions you already know.
- Put a fifteen-minute monthly review into the calendar.
Summary
First-line support for an internal tool is a small routine: one named person, three questions, clear escalation rules and a shared answer list that grows with every case. It protects the developer's time, helps users get answers sooner and shows you where the tool itself should improve.
Sources
- Our related articles linked above.
- The approach described here is common practice for small and mid-sized companies, used as a practical guide. No client results or market figures are claimed in this article.
