SaaS: why a first line of support comes before engineering

There is one message that reaches every software company and it is always written the same way: «it doesn't work». It does not say what stopped working, or since when, or with which account. And since nobody knows whether it is a product bug, a badly set permission or the wrong screen, it ends up where every uncertainty ends up: in the channel where the developers are.

For the first few months that holds. Then the product grows, the users grow, and the most expensive people in the company spend half their morning explaining where a password gets changed. The answer is not to reply faster. It is for that message not to arrive like that.

Half of what comes in is not a bug

Take your product's inbox, sort a full week of messages, and the list will look a lot like this: access incidents —passwords, permissions, locked accounts—, configuration questions, usage questions already answered in the documentation, known errors reported for the tenth time, and finally the real bugs: the ones that need somebody to touch code.

Only that last group needs your development team. The other four do not, and they are the majority. The trouble is they arrive mixed together, and separating them costs time as well: when the only person who can separate them is the one writing code, the sorting is paid for at engineering rates.

And the cost is not the minutes spent replying. It is the interruption. Pulling someone out of a technical problem to answer a question about a menu and putting them back afterwards does not cost five minutes: it costs five minutes plus the time it takes to get back in. And it happens several times a day.

The SaaS and software page sums it up in one line: your developers should not be your first line, since that way support is not done properly and neither is development.

What a real first line does

«First line» sounds like a filter, and a filter that only forwards is worth nothing: it just moves the work around. A first line that works does four concrete things, in this order.

It sorts. The first thing in the morning is not replying: it is looking at what came in and deciding what each item is. Usage question, access problem, known error, new bug. Once that is done, the queue stops being a pile and becomes four queues with different owners.

It resolves access and configuration. Passwords, permissions, locked accounts, options the user cannot find, badly connected integrations. That is real work and it is the largest share of the volume. It does not require knowing how to program: it requires knowing your product and having permission to act.

It reproduces before escalating. This is the one that changes the outcome, which is why it gets its own section below.

It documents what was resolved. Every answer written twice is an answer that should have been written once. Whoever handles the queue every day sees the repetitions and turns them into an article, a canned reply, or a warning that something in the product needs changing. That is what makes the queue shrink over the months instead of growing at the same rate as your user base.

That is the content of the job exactly as we publish it under tier-1 technical support. And the order matters: do the fourth without the first and you end up documenting what you remember rather than what comes in most.

Reproducing is the work, not a formality

A bug escalated without being reproduced is a bug that comes back. Engineering opens it, cannot see it, asks, waits for the user, the user replies two days later with half the information, and the case either dies or gets reopened. Engineering time has been spent fixing nothing.

Reproducing means provoking the failure on purpose and writing down what it takes to see it: the exact steps in order, the account and the permission level it happens with, the browser and the device, what the user expected and what actually happened, and whether it happens always or only sometimes. With that in front of them, a developer opens the case and is already inside the problem.

There is a side effect worth as much as the saving: while trying to reproduce them, a share of the bugs falls away. It was not a bug, it was a permission, a badly entered value, or an old version in the browser cache. That case never reaches engineering and nobody had to look at it twice.

And there is a third, quieter one: the user gets an earlier reply from someone who is genuinely looking at their problem, instead of a «we have passed it to the technical team» with no date on it.

What it does not do: it never touches code

Worth saying early, since it is the most common confusion whenever technical support comes up.

It does not write code. It does not go into the repository. It does not deploy. It does not fix errors in the product and it does not decide what enters the roadmap. Its work ends exactly where a developer's begins: at a case reproduced, documented and opened wherever your team works on it.

If what you are short of is hands on the product —improvements, integrations, automations— that is a different thing and a different conversation: the Tech pod. Mixing the two produces the classic failed hire: a technical profile asked to answer tickets, who ends up doing both badly.

What your team gains once the first line exists

Product people put it better than anyone: they stop receiving «it doesn't work».

Four things change in practice. They receive reproduced cases, with steps, environment and account. They receive fewer cases, since some of them were not bugs. They receive them in their own issue tracker rather than in a direct message mid-afternoon. And they get back long uninterrupted stretches, which is the only thing development really needs.

On the other side a figure appears that nobody was looking at and that shows up simply from having one person reading everything: what gets asked most. Three different users with the same question in the same week are not three tickets; they are a product or documentation problem. Whoever handles the queue daily sees it. Whoever drops in occasionally does not.

How to tell whether it is time

Four signs, and you do not need all four:

• A developer answers users every day, even if it is «only for a while».
• Questions get answered for the second and third time without anybody documenting them.
• Bugs are escalated with no steps to reproduce, and come back asking for them.
• First response time depends on somebody happening to look at the channel.

And if your product is complex enough that the right answer depends on knowing how it works inside, a first line is not a luxury: it is what stops every question from turning into an interruption.

Where to start

Measure a week before deciding anything. Take everything that came in, sort it into the five groups above and count how many fall into each. That number —the share that did not need engineering— is what makes the decision, and nothing else is required to have it.

With the number in front of you, the next step is to define what the first line resolves and what always gets escalated, and to write it down before day one. The first week is training on your product with everything reviewed before it goes out, and autonomy is usually around 80% by week four: how long it takes depends mostly on how well documented your product is, not on the person.

If you want to see the whole setup, it is on the technical support page. And if you are not sure your volume adds up to one full-time person, say so on the call: half an hour, and if we are not a fit we will tell you in that same conversation.