Your first support hire is a tier-one decision.
You are answering questions at night that your own documentation already answers. Hiring solves the symptom.
There is a stage every software company reaches where the founder is still the support team. Questions land in a shared inbox and a channel, and they get answered late, by whoever has the least broken concentration.
The tell that you have reached the end of that stage is not volume. It is repetition. You start recognising the questions. You start copying your previous answer. And somewhere in there you realise that almost every answer you send already exists, written down, in your own documentation.
That is the moment the hiring conversation starts. It is usually the wrong conversation.
What you would actually be hiring for
Sort the last month of questions into two piles.
The first pile is tier one: how do I do this, where is that setting, why did this fail, what does this error mean, does the plan include that. The answers exist. They are in your docs, your changelog, or a thread from a while back. They need retrieving and phrasing, not deciding.
The second pile is everything else: the bug nobody has seen, the customer deciding whether to renew, the integration that needs an engineer.
A support hire absorbs both piles, which is why hiring feels like it works. But you are paying a salary primarily to have your existing documentation read back to people, and the second pile — the one that actually needs a human — was never the bottleneck.
Why the bot you might build will not fix it
The reflex is to point a model at the docs and put a bot on the site. Most teams at this stage have already tried it, and most of those bots are sitting unused.
The reason is rarely answer quality. It is that the bot lives outside the work. It answers on a page nobody on the team visits, it has no permissions of its own, and it cannot do anything with what it learns. When a customer question needs a person, the bot cannot bring one — it can only stop.
So the team keeps working the way it always did, and the bot becomes a thing that exists.
What tier one looks like handled properly
An agent takes the first pass on the widget and on the inbound line. It answers from your knowledge, against the customer’s actual record, and it says so plainly when it does not know.
When the question belongs to a person, it escalates into the channel where your team already works, with the conversation and the record attached. Not a notification pointing at another tool. The thing itself, in the room, ready to be picked up.
Your qualified leads get the same treatment. A question from someone evaluating you gets an answer while they are still evaluating, instead of six hours later when they have moved on.
And because the agent is a member of the workspace rather than a service on a page, your team can mention it, correct it, and hand work to it the way they would with anyone else.
The actual decision
The question is not whether to hire someone. You will, eventually, and they will be valuable.
The question is what you want them working on when they arrive. If tier one is already handled, your first support hire spends their time on retention, on the hard cases, and on making the product need less support. If it is not, they spend it reading your documentation aloud, and you will be having this conversation again about the second hire.