The inbox that never lets up
Harsh Garg ran support for his own SaaS product solo, and by his own account it took over his day. "8 months ago, my support inbox was overwhelming. I was spending 3 hours a day on it personally," he wrote in an Indie Hackers post in April 2026. He hired someone to take it off his plate. That hire burned out and quit within eight weeks. He hired again. Same result.
When he finally sat down and pulled three months of ticket history instead of hiring a third time, the pattern was obvious: 61% of everything landing in the inbox already had an answer sitting in the FAQ. Not hard questions. The same questions, again and again. "I had been paying humans to answer FAQ questions at $40K/year," he wrote. His conclusion: "The fix wasn't a better hire. It was a system that handled the 61%."
Garg's product is B2B SaaS, not a D2C brand, so the specific questions are different (CRM connections and billing instead of ingredients and shipping windows). But the shape of the problem is the one I keep running into on the retail side too. On Shopify's own community forum, when merchants were asked what question they answer over and over, one described "Where is my order?" making up roughly 70% of tickets in some stores. Another, describing what's left once order-tracking notifications are automated, put it this way: the variations that leak through, "it says delivered but I never got it," "can I change my address before it ships," sizing and return-policy questions, "quietly eats the day" even though none of it looks urgent on its own.
Why repetitive questions cost more than they look like they should
A single "what's your return window" question takes thirty seconds to answer. Fifty of them in a day is a different problem entirely, not because any one of them is hard, but because someone has to read each message, recognize it as the same question they answered an hour ago, and retype a version of the same paragraph. The cost isn't the difficulty of the work. It's the volume of context-switching disguised as easy work.
The risk sits in a different place: getting one of these answers wrong. A support rep who's answered forty near-identical return questions today is more likely to slip on the forty-first, quote the wrong window, miss a state-specific exception, or (worse, in categories like supplements or skincare) give a confident answer to a safety-adjacent question that should never have been answered off the cuff. A wrong shipping answer is an annoyance. A wrong answer to "can I take this with my prescription" is a liability, and it's the kind of mistake that happens exactly when a team is moving fast to clear a backlog of easy tickets.
Garg's story is also the clearest evidence I've seen for something I've suspected for a while: hiring doesn't fix this problem in a straight line. Adding a person adds capacity, but it doesn't remove the repetition, it just moves the same repetitive task onto a new set of shoulders. Two hires burned out on his inbox for the same reason: most of what they were doing wasn't the interesting or hard part of the job. It was retyping answers that were already sitting in a document somewhere.
What a solution could look like
There's a spectrum of ways teams try to solve this, and it's worth being honest about what each one actually fixes.
Canned response macros. Fast to set up, and they do save typing time. But a person still has to read every ticket, decide which macro applies, and hit send. They remove the writing, not the judgment or the volume of attention.
A generic chatbot widget.Bolt-on chat tools are quick to install and look automated from the outside. The problem is grounding: most of them answer from a general model or a shallow FAQ scrape, not the brand's actual, current policy. That's exactly how a bot ends up confidently telling a customer the return window is 30 days when the brand's real policy is 45.
Outsourced support. Buys capacity without the hiring and training overhead, but it inherits the same repetition problem Garg described, just moved to a different company. It also adds a layer between the brand and the answer, which makes correcting a wrong answer slower, not faster.
Hiring more people.Works, until it doesn't. It scales roughly linearly with volume, and as Garg's experience shows, repetitive-question volume is a bad job to hire humans into: the work is too easy to be engaging and too voluminous to be light.
A custom grounded-answer system.Built to answer from the brand's actual product, policy, and ingredient data, with a deliberate line drawn around what it's allowed to answer alone. This is the option that actually addresses both halves of the problem: it removes the repetition without removing the accuracy, and it's the one I'll walk through below.
The solution I'd build
Here's how I'd build this. The first decision has nothing to do with the AI model. It's about grounding. Before anything drafts a reply, it looks up the brand's actual current policy: shipping windows, return terms, ingredient and allergen data, sizing charts, whatever the brand has documented. Answer before grounding and you get a system that sounds confident and is sometimes just wrong, which is worse than a slow human, because a wrong answer that reads as authoritative is harder for a customer to question.
Second, I'd separate classifying a question from answering it, and do them in that order. The first pass figures out what kind of question this is (shipping, ingredient, sizing, a safety-adjacent question) and how much certainty the answer needs. Only then does a second pass draft the actual reply, pulling from the specific part of the knowledge base that question maps to. Skip this step and you get a system that occasionally writes a well-worded answer to the wrong question, which is a strange kind of failure to explain to a customer.
Third, and this is the piece that actually makes it safe to switch on: a confidence threshold. If the system is confident enough, in a version of this I've built for simulated D2C ticket volume, that threshold sat around 0.7, the answer goes out automatically. Below that line, nothing gets sent. The question gets logged and handed to a person, with the drafted answer attached so they're editing, not starting from a blank page.
Fourth, some categories should never clear the automatic-send bar regardless of how confident the system is. A medication-interaction question, an allergic-reaction report, anything where being wrong has a safety consequence rather than just an inconvenience one, gets routed to a person by category, not by confidence score. Confidence measures whether the system thinks it's right. It says nothing about whether the system should be the one deciding.
Pros and cons
The upside is real: consistent, accurate answers at any hour, first response measured in seconds instead of the next business day, and a team that spends its attention on the tickets that actually need a person's judgment instead of retyping the same paragraph on autopilot.
The downside deserves equal weight. A system like this is only as accurate as the data it's grounded in, and a brand that changes its return policy or reformulates a product without updating the knowledge base will get a confidently wrong answer out the door before anyone notices. The medical and safety carve-out has to be treated as a hard rule, not a confidence score, because there is no accuracy threshold high enough to make an automated answer to a medication question acceptable if it's wrong even once. Keeping the knowledge base current is an ongoing job, not a one-time setup, and it's easy to underestimate how much that upkeep costs against the time it saves. And there's a trust risk on the customer side too: an automated answer that reads as evasive or generic, even if it's technically correct, can do more damage to trust than a slower human reply would have.
How this gets built
The technical shape, stripped of any particular vendor: a ticket comes in through whatever channel the brand already uses (email, chat widget, DM). It's checked against the brand's knowledge base first, before any reply is generated, so every answer is grounded in current policy rather than a model's guess at what's typical. A classification pass tags the category and the certainty required. A drafting pass writes the reply from the retrieved, relevant section of the knowledge base, not from the whole document. A confidence score decides whether that draft goes out automatically or gets logged and routed to a person, with category-based overrides for anything safety-adjacent that bypass the confidence check entirely. Everything that gets escalated arrives with the draft already attached, so the human is reviewing and editing, not writing from nothing.
What the numbers say
The clearest cited figure I have for this is from Freshworks' own 2025 research on AI in customer service: across retail companies using its Freddy AI Agent, 53% of incoming queries were resolved by AI without a human, first response time dropped from about 12 minutes to about 12 seconds, and resolution time dropped from over an hour to around 2 minutes. Worth being straightforward about what this is: it's Freshworks reporting on its own product's customers, not independent third-party research, so treat it as a vendor-reported result rather than a neutral benchmark.
Where this is documented directly, in the sense of specific, named use cases I've seen in beauty and cosmetics (a product-safety question like "is this vegan") and in health, nutrition, and wellness (a medication-interaction question). The same shape likely holds in other categories that field a lot of recurring factual questions: fashion sizing, food and beverage ingredients, home goods assembly. But those extensions aren't part of the research behind this post, so I'm not claiming them as documented, only as plausible. What does carry across every category is the one rule that matters most: a "does this ship to Canada" question can go fully automated. "Can I take this with my prescription" should always go to a person, no matter how good the underlying system gets.