Chatbot

Questions arrive around the clock while the people who answer them work office hours. A customer whose payment fails at seven on a Friday evening waits until Monday morning, and sends the same question again by email in the meantime.

The questions also look remarkably alike. How do I change my password, how do I invite a teammate, when is my card charged — the same three every day. Support staff retyped the same sentences ten times a day, and doubling the customer count doubled that repetition. Hire your way through it and cost climbs at the same slope as the customer base.

Writing good help articles doesn't close the gap either. Articles only get read if someone goes looking, and a customer who is stuck hits the chat button instead of searching the documentation. A chatbot exists to put the answer behind that button. The idea is to hand over the answer in the place the customer has already walked to.

The first thing it cuts is waiting. First response time (FRT) — how long it takes for a first reply after a question arrives — usually runs tens of minutes even during office hours and past ten hours overnight or at weekends. A chatbot answers in seconds whenever the question comes in. The answer doesn't even have to be complete. Confirmation that the question landed, plus a rough direction, is enough to stop the customer from sending the same thing through a second channel.

The second is the volume of repeat questions. Ticket deflection is the share of questions that get resolved through self-service and never become a case at all, and a chatbot works by pushing that number up. In a product taking 100 questions a day, 30 ending at the bot leaves 70 for humans. Those 30 are usually the 30 easiest ones, so the average difficulty of what remains goes up while the time available per case goes up with it.

The third is the distance to the documentation. A knowledge base — the article library customers are supposed to browse themselves — often goes unread even when it's well built, because people don't know what words to type into the search box. A chatbot takes the question in whatever words the customer already uses and surfaces the matching article. Type "I can't add a teammate" and it pulls up the page about invite permissions.

All three come with one condition attached. The answer has to be written down somewhere for the bot to fetch. Bolt a chatbot onto thin documentation and it becomes a machine for saying "I didn't understand that" very quickly.

Three other things solve the same problem, and the choice comes down to how many questions arrive and how alike they are.

1. An FAQ — recurring questions and their answers collected on one page. Under about ten distinct questions, this beats a chatbot outright. Past twenty, finding your own question in the list becomes work by itself.
2. Macros — saved reply templates a support agent pulls in with a couple of clicks. A person is still answering, but each case takes less time, and because the agent adjusts the text to the situation the quality holds up. This suits products with modest volume where every case differs.
3. Hiring more people — the most reliable option and the most expensive. For products where questions vary every time, or where the customers are large accounts, this is the sensible choice. If a team handles 20 support tickets a day, maintaining a bot can cost more effort than one more person.

The range where a chatbot fits is high volume with heavy repetition. More than 50 questions a day, with ten recurring ones making up half of them, is worth the build.

The technical choice splits too. A bot that only answers a fixed set of questions misunderstands a lot but never invents an answer. Built on a large language model (LLM), a model trained on huge amounts of text to handle language, it understands rephrasings but can also produce confident answers that appear nowhere in the documentation. For anything costly to get wrong — refund policy, pricing — the model is blocked from composing a reply and made to pull a fixed one instead.

"Let's fill in the help center before we add a bot. Right now there's nothing for it to fetch."

Bot performance is bounded by how thick the documentation is.

"Our bot resolves 30 percent. Is that a good number?"

Three in ten cases never reached a human, and a low figure means fixing the articles or the recognition.

"Put the talk-to-a-human button on the first screen. Two dead ends and the customer just leaves."

Leaving an exit open beats insisting on automated handling.

At Pagedeck this came up when free-plan growth took daily questions from 40 to 110. Sofia counted a month of cases by reason and found that invites and permissions accounted for half of them. Rather than starting with a bot, Mia put rewriting the articles behind that half at the front of the queue.

Once the articles were fixed, Theo connected a chatbot, taught it the twelve most common questions, and routed everything else straight to a person. Resolution came in at 34 percent the first month. Sofia read the opening line of every handed-off case each week and collected the phrasings the bot had missed, and that list became the next month's documentation fixes.

The most common belief is that installing a chatbot reduces the number of questions. It's a tool you switch on, so it seems fair to expect the result to switch on with it. What a bot actually does is fetch answers that already exist rather than produce new ones. Connect one to thin documentation and the customer gets two or three non-answers before asking for a human, which adds a step to a case instead of removing one. A bot stuck in the low teens on resolution rate usually has a documentation problem, not a recognition problem.

Reading it as a replacement for people is the other one. A tool went in, so headcount should come down — the arithmetic suggests itself. But what the bot takes away is the easy cases, and what stays behind needs a human. The work shrinks and gets harder at the same time. On top of that, the bot itself becomes something to maintain: reading the questions it missed, fixing articles, adjusting replies. If nobody owns that, six months later the product has changed and the bot is still giving last season's answers.