What to Automate First When You Have One Support Person

A one-person support desk doesn’t fail the way people expect. It doesn’t collapse under volume. It erodes. The same twenty minutes of repetitive replies burn off every morning, and the ticket that actually needed thinking sits there until Thursday. Automation can help. But only if you aim it at the right thing. Aim badly and you’ve bought yourself a system to babysit on top of a queue you were already losing.

Start by Reading Your Own Inbox, Not a Feature List

Before you look at a single tool, spend a week tagging incoming tickets by question type instead of by product line or channel. Channel tells you where people showed up. Question type tells you what they wanted, and only that second thing can be handed to software.

What you’re hunting for is repetition. If the same question lands phrased five different ways, that’s one automation candidate, not five. Your support person knows those answers cold, which is exactly why they were never written down anywhere a bot could reach them. Knowledge that lives in one head looks like efficiency right up until that head goes on holiday.

Here’s a method that takes an afternoon. Export the last two hundred tickets, sort by the text of the first reply, and scan for replies your person has basically copy-pasted. Those near-identical first responses are your shortlist, ranked by how often they show up.

The failure here is predictable. Teams pick automation targets from what feels irritating rather than what’s actually frequent, then burn three weeks automating a memorable edge case that appears twice a quarter. Annoyance and frequency are different measurements. Only one of them pays back the setup. If you want a wider view of the trade-offs first, there’s more on support automation worth reading before you commit a month to it.

The Three Ticket Types Worth Handing Over First

Three categories belong at the front of the queue, and you can match them against your tagged export in minutes.

• Status and lookup questions. “Where is my order”, “is the blue one back in stock”, “what time do you close on Saturday”. High volume, near-zero judgement, and the answer already exists in writing somewhere.
• Policy and process questions. “How do returns work”, “do you ship to Norway”, “what does the warranty actually cover”. Stable, and they live in a document. Or they should.
• Pre-purchase questions from people who aren’t customers yet. “Does this fit a 2019 model”, “what’s the difference between the two sizes”. A solo support person answers these last, after the existing customers, and quietly loses the sale in the gap.

The thread running through all three matters more than the categories: each has one correct answer that doesn’t change based on who’s asking or how annoyed they sound. That property is what makes a question safe to automate. It’s also a decent test for anything else you’re tempted to add later.

What Should Never Leave the Human’s Desk

Some tickets stay with your person no matter how good the tooling gets. Anything involving money moving in the wrong direction - refunds, chargebacks, billing disputes, cancellations where you could still save the account - belongs to a human who can read the room and make an exception.

Complaints from customers who are already angry, that’s the second category. A technically correct answer delivered by a bot to someone who wanted acknowledgement doesn’t resolve the ticket. It escalates it. The person wasn’t asking for information.

Third: anything where the honest answer is it depends, and the dependencies live in someone’s head instead of a document. If your person can’t write the decision rule down in three sentences, a knowledge base can’t hold it either.

For a one-person desk, add a hard rule on top: anything that could turn into a public review or a legal question stays with the human. No exceptions. Bigger operations can automate parts of this with tight scoping and a supervisor reading transcripts daily. A solo desk can’t afford that supervision, and buying time back was the whole point.

Your Knowledge Base Is the Actual Project

The bot isn’t the work. Assembling the source material is the work, and this is where most solo rollouts stall out - somewhere in week two, admin panel configured, nothing useful to feed it.

Botino builds its answers from a knowledge base you upload: documents, guides, FAQs and other source files. Which has an obvious consequence. The quality ceiling of every answer is set by what you upload, so a vague FAQ gets you a vague bot. Every time. It’s worth checking what the platform can do with that material before you decide how much of it to write.

Start with the replies your person already sends. Pull the ten most repeated ones out of the mail client and turn each into a short, plain document. Faster than writing from scratch, and more accurate too, because those replies have already survived contact with real customers.

Write for retrieval, not for reading. One question per section, product and policy names spelled out every single time, and no “as mentioned above” - the system may never see what was above. What separates a working rollout from a dead one is usually mundane: documents that state the current policy in plain terms, versus documents vague enough to stay technically true.

The First Month, In Order

Week one: tag tickets, pick the top three question types, write the source documents. No bot configuration at all. Don’t open the tool. Seriously - the urge to configure something before you know what it should say is the main reason month one drifts into month three.

Week two: register and set up the first voicebot, which is free after registration. In the admin panel you configure the bot’s name, tone, scope and knowledge base. Keep the scope deliberately narrow: the three question types you picked, nothing adjacent.

Week three: run it internally, or on a low-traffic channel. Ask it the real questions from your ticket export, word for word, including the badly phrased ones. When an answer comes out wrong, fix the document, not the wording of the configuration. Prompt tinkering hides gaps in the source material instead of closing them.

Week four: put it in front of customers with a visible, easy route to a human, and read every conversation yourself. Don’t add a second use case until the first one answers correctly while nobody’s watching.

Escalation Is a Design Decision, Not a Fallback

Decide up front what happens when the bot doesn’t know. A clean handover message beats a confident guess every time, and you make that choice during configuration, not mid-conversation.

Botino’s guided conversations answer from the knowledge base and point people toward the right information, which works well when the boundary is explicit in the configured scope. A bot with a narrow, well-stated remit says “I can’t help with that, here’s who can” and that’s that. One with a vague remit improvises. And improvisation is where trust goes to die.

As general practice, handoff routing and conversation review sit outside the bot itself. Plan them anyway: decide who reads unresolved conversations and when, before launch rather than after the first complaint. The mechanics of handing a chat to a human are worth settling before you write the handover message.

For a solo desk, batch the escalations. One review slot per day beats a stream of interruptions, which was the original problem you were trying to solve. Multilingual support changes the maths here - if the bot answers in a language your person doesn’t speak, tighten the scope further, because you can’t supervise what you can’t read.

Knowing Whether It Actually Worked

Judge this by your person’s calendar, not by conversation counts. Did the repetitive replies drop out of the working day? Did the thoughtful tickets get answered the same afternoon instead of three days later? Volume handled is a vanity number at this size. If you do want a harder number later, how to measure containment rate is the place to start.

Read transcripts by hand in the early weeks. A one-person desk has few enough conversations that sampling is pointless, and reading all of them teaches you more about your customers’ actual vocabulary than any summary will.

Two failure signals deserve standing attention. First, customers rephrasing the same question over and over - retrieval is missing something your documents should cover. Second, escalations arriving with less context than before, which means the bot is absorbing the useful part of the conversation and handing you the residue.

Update the knowledge base on a fixed cadence tied to policy changes, or it quietly turns into a source of outdated answers. Automation on a one-person desk was never about handling more volume. It’s about protecting the hours where judgement actually matters.