In the AI projects we develop at Soamee, few things surprise us as much as the disproportion between the cost of a solution and its real impact. This is the story of a feature that cost less than $30 a month to run and reduced support tickets for a SaaS client by 40% in the first eight weeks.
No large models. No exotic infrastructure. Just a simple idea, well executed, with the right language model for the job.
The Problem: a Support Team Drowning in Repetitive Questions #
When the client came to us, their support team was handling between 800 and 1,200 tickets a month. The problem wasn’t the complexity of the queries — it was the opposite: 60% of tickets were variations of the same 30 questions.
“How do I export my data?”, “Can I change my plan from the dashboard?”, “Why isn’t my confirmation email arriving?”. Questions that anyone who read the documentation could answer in two minutes. But users preferred opening a ticket to searching for the answer themselves.
The direct cost was obvious: agent hours spent answering questions whose answers were already written down. But the indirect cost was worse: complex tickets — the ones that genuinely required human intervention — were taking longer to receive attention because the queue was blocked by simple questions.
The most obvious solution would have been to hire more agents. But the team was small, the budget tight, and scaling human support doesn’t solve the underlying problem: the friction between the user and the existing documentation.
The Idea: What If We Just Answered the Easy Ones? #
The key insight was this: we don’t need a sophisticated AI agent. We need something that reads the existing FAQs and can respond in natural language when a user asks the same thing in different words.
Basic RAG. A small, cheap model. Fallback to human when confidence is low. Nothing more.
The temptation in these projects is to over-engineer the solution. Add conversational memory, integrate the CRM, build a multi-step agent with access to internal APIs. All of that might make sense in later phases. But in phase zero, the right question is: what is the minimum feature that solves 80% of the problem?
In this case, the answer was clear: a FAQ auto-responder based on semantic search and a low-cost LLM.
The Architecture: Simple by Design #
The system we built has four components and can be diagrammed on a napkin:
1. Indexed Knowledge Base
We took the client’s 47 existing knowledge base articles (in Markdown format) and processed them with an ingestion script. Each article is split into chunks of ~500 tokens with 50-token overlap to preserve context between paragraphs. Each chunk is converted into an embedding vector using OpenAI’s text-embedding-3-small
model (cost: $0.00002 per 1,000 tokens; the full ingestion cost less than $0.05).
The vectors are stored in a lightweight vector database (we used Qdrant on a self-hosted instance, though Supabase with pgvector works equally well at this volume).
2. Semantic Search Endpoint
When a user types a query in the support widget, before a ticket is opened, the text passes through our endpoint. It’s converted to an embedding, the 3 most relevant chunks are retrieved by cosine similarity, and a prompt is built containing:
- The user’s original query
- The 3 retrieved documentation chunks
- A system instruction asking for a concise response, in the brand’s tone, with an explicit instruction not to invent information not present in the context
3. Low-Cost LLM with Caching
The resulting prompt goes to Claude Haiku (or GPT-4o-mini, depending on preference). These models cost ~$0.001 per 1,000 input tokens and ~$0.002 per 1,000 output tokens. A typical prompt has 600-800 input tokens and generates 150-250 output tokens. The cost per query is approximately $0.0015-$0.0025.
Semantic caching is the element that most reduces cost in production. For the most frequent queries (representing 35-40% of total volume), the system returns the cached response without calling the LLM. The effective cost of those queries is virtually zero.
4. Fallback Logic
The system includes a confidence score based on the similarity score of the closest result. If the most relevant chunk has a similarity below 0.72 (a threshold calibrated during the first weeks), the system doesn’t respond automatically. Instead, it shows the user the most relevant documentation found and offers the option to open a ticket, with the search context pre-filled for the agent.
This ensures the system only responds when it has a basis to do so. The hallucination rate observed in production was below 0.5%.
The Cost Breakdown: $0.002 Per Query #
The table below shows the real monthly cost of the system in production, with a volume of ~1,000 queries per month:
| Component | Detail | Cost/month |
|---|---|---|
| Query embeddings | 1,000 queries × ~300 tokens | ~$0.006 |
| LLM (Claude Haiku) | 600 uncached queries × ~1,000 tokens | ~$1.20 |
| Vector database | Qdrant cloud (basic tier) | $10.00 |
| Server/API | Serverless function (AWS Lambda) | ~$2.00 |
| Weekly doc re-ingestion | Content updates | ~$0.10 |
Total | ~$13-15/month | With caching enabled for the most frequent queries, the effective cost per resolved query is $0.002. For cached queries, the cost is $0.00.
What previously cost hours of agent time now costs less than a cup of coffee.
The Results: Eight Weeks Later #
Before the system, the team processed an average of 950 tickets a month. Eight weeks after deployment:
Ticket reduction: -40% The system autonomously resolved 40% of the queries that previously generated tickets. It didn’t deflect them, didn’t ignore them: it answered them satisfactorily without human intervention.
Response time: 3-second average The system’s response time is nearly instantaneous from the user’s perspective. Compared to the previous wait time (which could be 4-24 hours depending on team load), the perceived improvement was significant.
Satisfaction: 92% positive ratings
We implemented a micro-rating at the end of each automatic response (thumbs up / thumbs down). 92% of automated responses received positive ratings. The remaining 8% led to a ticket with pre-filled context.
Complex tickets getting more attention
With 40% less load in the queue, agents could dedicate more time to tickets that genuinely needed it. The average resolution time for complex tickets dropped from 18 hours to 11 hours.
What Surprised Us: Users Prefer AI for Simple Questions #
The most unexpected result wasn’t quantitative but qualitative. In the early weeks, we received anecdotal feedback from users who said they preferred the automatic response to waiting for an agent on simple questions.
The reason is intuitive: if you know your question is simple, the friction of waiting for a human response (however minimal) feels disproportionate. An instant response, even from an AI, eliminates that friction.
This also taught us something about designing these systems: transparency matters. The widget clearly indicated “Automatic response based on our documentation.” It wasn’t trying to pass as human. And that, far from generating distrust, generated trust: users knew exactly what they were receiving and why.
What Didn’t Work: The System’s Limits #
Honesty is part of the design. This system has clear limits and it’s important to acknowledge them.
Complex technical incidents
When a user reports a bug with specific reproduction steps, error logs, or unexpected behavior, the RAG system can’t help. The documentation doesn’t contain that level of specificity. These cases always go to a human agent, and they should.
Complaints and emotional situations
A frustrated user who has had a problem for days doesn’t want a documentation response. They want to feel heard. The system detects frustration patterns in the text (words like “unacceptable,” “I’ve been waiting weeks,” “I want to cancel”) and escalates directly to human without attempting to respond with documentation.
Questions that imply account context
“How many users can I add on my current plan?” looks like an FAQ question but requires knowing the user’s specific plan. Without CRM access, the system responds with the generic plan information and recommends checking in account settings. In phase two of the project, adding a session token to let the system know the user’s active plan is planned.
Onboarding new flows
When the product launches a new feature, there’s a 1-2 week period until the documentation is updated and re-ingested. During that period, questions about the new feature go to an agent. It’s the only structural lag in the system.
The Math: $30 a Month vs. What Agent Time Actually Costs #
Let’s put the numbers in perspective. A dedicated support agent in a typical SaaS company costs the company roughly $3,000-4,000 a month fully loaded. Their ticket handling capacity, assuming they spend 70% of their time responding to queries, is around 400-600 tickets a month.
The AI system resolved 380 tickets a month (40% of 950) at a cost of $15. If a human agent had handled those tickets, they would have represented 65-95% of their monthly capacity.
We’re not saying AI replaces the agent. We’re saying it frees the agent to do the work only a human can do well.
The ROI in this case was several orders of magnitude. And the initial implementation investment was recovered in the first two weeks of operation.
How to Replicate This in Your Product #
If you have a SaaS with an existing knowledge base and a support volume that’s starting to become a burden, this is the most direct path: Week 1: Audit your tickets from the last 3 months. Classify queries by category. If 40-60% are questions whose answers already exist in your documentation, you have a clear use case.
Week 2: Documentation ingestion. Convert your articles to Markdown if they aren’t already, split them into chunks, generate embeddings. This process is technical but not complex.
Week 3: Build the minimum endpoint. Semantic search + prompt + LLM + fallback logic. Don’t add more functionality until this works.
Week 4: Deploy in shadow mode (the AI generates responses but a human reviews them before sending). Calibrate the confidence threshold. Adjust the prompt based on errors you observe.
Weeks 5-8: Activate autonomous mode for the categories with highest confidence. Monitor satisfaction rate. Iterate.
The underlying principle is always the same: start small, measure everything, iterate on real data.
Conclusion: AI Doesn’t Have to Be Expensive to Be Useful #
The dominant narrative about AI in business tends to revolve around major transformations, complex platforms, and six-figure budgets. But some of the most significant impacts we’ve seen in our projects come from small, well-defined features that solve a specific problem with modest technology.
$0.002 per query. $15 a month. 40% fewer tickets. 92% satisfaction.
Those numbers aren’t exceptional because the technology is sophisticated. They’re exceptional because the technology is the right fit for the problem.
If your support team spends time answering questions that are already answered in your documentation, you have a problem that AI can solve today, with publicly available models, at a cost that needs no executive justification. At Soamee we work on exactly these kinds of projects: practical AI solutions that generate measurable impact without unnecessary infrastructure. If you want to explore whether something like this makes sense for your product, tell us your context.