How We Built Our Own Support Bot

There is a saying in software: eat your own dog food. If you build a product, you should use it. Not just test it — genuinely rely on it for your own business operations. It is the fastest way to discover usability issues, missing features, and the gap between what you think your product does and what it actually does in practice.

We are LoopReply. We build an AI chatbot platform. And yes, our own support bot is built on LoopReply.

This is not a marketing statement. It is the full, unvarnished story of how we built our own support bot using the same tools our customers use — the same workflow builder, the same knowledge base, the same human handover, the same analytics. We are going to share what worked, what did not, what surprised us, the bugs we found in our own product because of this process, and the specific lessons that made both our bot and our platform better.

If you are considering building a support bot with LoopReply (or any platform), this behind-the-scenes look will give you a realistic picture of what the process involves.

Table of Contents

• Why We Built Our Own Support Bot
• The Setup: What We Started With
• Building the Knowledge Base: What We Got Right and Wrong
• Designing the Workflows
• The Launch and First Week Reality Check
• What Broke (Honestly)
• What Worked Better Than Expected
• How We Optimized Over 90 Days
• The Numbers: Our Bot's Performance
• What This Taught Us About Our Product
• Frequently Asked Questions
• Conclusion

Why We Built Our Own Support Bot

Three reasons drove the decision.

1. Credibility. If we are going to tell businesses to use LoopReply for their support, we had better be using it ourselves. Nothing undermines trust faster than a chatbot company that uses email-only support. We needed to demonstrate that our product works by putting it in the highest-stakes environment possible — our own customer interactions.

2. Product improvement. Using our own product for real support conversations surfaces bugs, UX issues, and missing features that internal testing never catches. When you are answering a customer's question and the bot fails to pull the right knowledge base article, you feel the frustration firsthand. That empathy drives better product decisions.

3. Support scalability. As a growing startup, we could not afford to hire a dedicated support team for every new customer segment. We needed our support to scale without headcount scaling proportionally. If our own product could not solve this for us, we had a problem.

The Setup: What We Started With

When we decided to deploy our own support bot, our support situation looked like this:

• Team: 3 people who handled support part-time alongside their primary roles (product, engineering, customer success)
• Volume: 45-60 support conversations per day via email and an early version of our chat widget
• Common topics: Feature questions (30%), technical troubleshooting (25%), pricing and billing (15%), onboarding help (15%), bug reports (10%), other (5%)
• Response time: Average 3.5 hours (we were not proud of this)
• Coverage: Approximately 10 hours per day, 5 days per week — meaning weekend and evening inquiries waited until Monday or the next morning

We set a goal: deploy a bot that resolves 60% of conversations without human intervention, responds in under 5 seconds, and maintains a satisfaction score of 4.0 or higher. We gave ourselves 2 weeks to build and launch.

Building the Knowledge Base: What We Got Right and Wrong

What We Got Right

We started by uploading everything we had:

• All help center articles — 120+ articles covering every feature, integration, and workflow
• API documentation — full API reference for developers
• Changelog entries — 6 months of product updates
• Pricing page content — plan details, feature comparison, FAQ
• Onboarding guides — step-by-step setup for different use cases (e-commerce, SaaS, healthcare, etc.)
• Integration documentation — setup guides for all 30+ integrations

We also mined our support inbox for the 100 most frequently asked questions and wrote detailed answers for each one. This took about 8 hours and was the single highest-value activity in the entire setup.

Total initial knowledge base: 187 documents. Far more than what we recommend as a minimum for our customers (30-50), because we had extensive existing documentation.

What We Got Wrong

Problem 1: Documentation was written for developers, not users. Our help center articles were technically accurate but assumed a level of familiarity that many of our users did not have. When a non-technical user asked "How do I make my chatbot respond to questions about my products?", our knowledge base article was titled "Configuring RAG retrieval pipelines for domain-specific knowledge bases." The bot found the right article but delivered the answer in language the user did not understand.

We spent 3 days rewriting our top 50 articles in plain language, keeping the technical versions available but ensuring the primary knowledge base spoke the language of our actual users — business owners, marketing managers, and support leads, not engineers.

Problem 2: We forgot about the obvious stuff. Our knowledge base covered every feature in depth but missed basic questions like "What is LoopReply?", "How is it different from Intercom?", "Do you have a free plan?", and "Can I try it before buying?" These are the questions a first-time visitor asks, and they are so obvious to us as the product team that we never thought to document them.

We added 25 "awareness-level" Q&A pairs covering the questions that someone who has never heard of LoopReply would ask. Bot performance on first-time visitor conversations improved immediately.

Problem 3: We did not account for how people actually phrase questions. Our knowledge base answered "How to configure human handover" perfectly. But users do not type that. They type "how do I transfer to a real person" or "can the bot send chats to my team" or "what happens when the AI can't answer." We needed to ensure our knowledge base covered the concept, not just the feature name.

This is actually a strength of RAG-based retrieval — it matches on meaning, not just keywords. But we found that adding natural-language variations of key concepts to our knowledge base documents significantly improved retrieval accuracy.

Designing the Workflows

We built five core workflows using our own visual workflow builder.

1. Welcome and Routing Flow

The opening flow determined the visitor's intent and routed them appropriately:

• New visitor: "Hey! Looking to learn about LoopReply, or are you an existing customer needing help?"

  • "Learn about LoopReply" → Product information flow
  • "Existing customer" → Support flow
  • "Pricing" → Pricing flow

• Returning user (identified): "Welcome back! Need help with your bot, or have a question about your account?"

2. Product Information Flow

For visitors exploring LoopReply, the bot acted as a knowledgeable sales assistant:

• Answered feature questions from the knowledge base
• Compared LoopReply to alternatives when asked ("How are you different from Tidio?")
• Directed to relevant feature pages, use case pages, and comparison pages
• Offered to start a free trial or book a demo

3. Technical Support Flow

For existing customers with issues:

• Asked which feature or integration they needed help with
• Searched the knowledge base for relevant solutions
• Walked through troubleshooting steps
• Escalated to our team via human handover if unresolved after 4 messages

4. Billing and Account Flow

For pricing, plan changes, and billing inquiries:

• Answered pricing questions from current plan data
• Directed plan change requests to our billing portal
• Escalated complex billing issues (refunds, enterprise pricing, custom plans) to our team

5. Bug Report Flow

For users reporting issues:

• Collected environment details (browser, OS, account ID)
• Checked against known issues in our knowledge base
• If a new bug, collected reproduction steps and screenshots
• Created a structured bug report and escalated to our engineering team

Design Decision: Explicit Routing vs. AI Classification

We debated whether to let the AI classify intent automatically or present explicit options. We chose a hybrid: the opening message presents clear choices, but once in a conversation, the AI classifies follow-up questions dynamically. This gave us the best of both worlds — clear entry points that set user expectations, with the flexibility of AI understanding for the natural flow of conversation.

The Launch and First Week Reality Check

We launched the bot to 100% of our website traffic on a Monday morning. We should have done a staged rollout (like we recommend to our customers). We did not, because we were confident in our own product.

Day 1: Humbling

The bot handled 47 conversations. It resolved 29 of them (62% resolution rate). Not bad for day one. But the 18 conversations that failed revealed problems we had not anticipated:

• 4 conversations about our mobile experience — we had no mobile-specific documentation in the knowledge base
• 3 conversations where users asked about features we had recently deprecated — our knowledge base still referenced them
• 3 conversations where the bot's tone was too casual for enterprise prospects asking serious security questions
• 2 conversations where the bot looped, repeating the same answer when the user asked a follow-up variation of the same question
• 6 conversations where the knowledge base had the right answer but the bot's summary was too long or too technical

Day 2-3: Rapid Fixes

We spent the next two days making fixes:

• Added mobile experience documentation (6 articles)
• Removed deprecated feature references (12 documents updated)
• Created a separate "enterprise tone" instruction set for questions containing keywords like "security," "compliance," "SOC 2," "enterprise," and "procurement"
• Fixed the looping issue (which turned out to be a bug in our conversation context handling — more on this below)
• Added response formatting guidelines: keep answers under 100 words, use bullet points for lists, end with a follow-up question or next step

Day 4-7: Stabilization

By the end of the first week, the bot was handling 50-55 conversations per day with a 68% resolution rate and 4.1 satisfaction score. Not yet at our 60% target on satisfaction score — wait, we were actually above our resolution target and close on satisfaction. The trajectory was encouraging.

What Broke (Honestly)

This is the part where dogfooding earned its keep. Using our own product for real customer interactions revealed problems that internal testing never would have caught.

Bug 1: The Conversation Context Loop

When a user asked a follow-up question that was semantically similar to their original question (for example, "What integrations do you support?" followed by "Which tools do you connect with?"), the bot sometimes re-retrieved the same knowledge base article and generated an almost identical response. The user would then rephrase again, getting the same answer again — a frustrating loop.

Root cause: Our conversation context was not being properly weighted in the RAG retrieval query. The system was treating each message independently rather than considering the full conversation context.

Fix: We updated our retrieval pipeline to include conversation history as context, so follow-up questions are interpreted in light of what has already been discussed. If the same article is retrieved twice, the system now generates a differently framed response or asks a clarifying question.

Impact: This fix improved the product for all LoopReply customers, not just our own bot. We would not have found this bug without dogfooding.

Bug 2: Opening Message Timing on Mobile

Our chat widget's opening message appeared immediately on mobile, before the page had fully loaded. On slower connections, this meant the chat widget was the first thing users saw — before the page content. It felt intrusive and was getting dismissed immediately.

Fix: We added a configurable delay (defaulting to 3 seconds on mobile, 2 seconds on desktop) and ensured the widget loaded after the main page content. This is now a setting all LoopReply customers benefit from.

Bug 3: Knowledge Base Freshness

We discovered that when we updated a knowledge base document, the updated content was not immediately available to the bot. There was a caching delay of up to 15 minutes. For most customers, this is fine. For us, when we updated our pricing page and a user asked about pricing 5 minutes later getting the old pricing — it was a problem.

Fix: We implemented near-real-time knowledge base indexing for document updates. Changes are now available to the bot within 60 seconds of upload.

Not a Bug, but a Learning: Tone Mismatch

Our bot was configured with a friendly, casual tone that matched our brand. But when enterprise prospects asked about security certifications, HIPAA compliance, or SOC 2 status, the casual tone felt dismissive. "Hey! Great question. Yeah, we're SOC 2 Type II certified and HIPAA-ready!" is technically accurate but does not inspire confidence in a CISO evaluating a vendor.

Fix: We implemented context-sensitive tone adjustment. For queries containing security, compliance, or enterprise keywords, the bot switches to a more professional, detailed tone. This is now a configurable feature in the bot personality settings for all customers.

What Worked Better Than Expected

1. Pre-Sales Conversion

We did not build the bot primarily for sales. But visitors who engaged with the bot before signing up had a 34% higher trial conversion rate than those who did not. The bot answered product questions, addressed concerns, and built enough confidence for the visitor to start a free trial — all without a sales call.

The most valuable pre-sales conversations were comparisons. When a visitor asked "How is LoopReply different from Chatbase?" or "Why should I choose you over Tidio?", the bot provided a nuanced, honest comparison (we have detailed comparison pages in our knowledge base). These conversations converted at 2.3x the rate of generic product questions.

2. Documentation Discovery

Our bot became the primary way users discovered our documentation. Before the bot, users had to navigate to our help center, search for the right article, and hope they used the right keywords. With the bot, users described their problem in natural language and the bot served the relevant documentation in the conversation, with a link to the full article.

Help center page views from bot-initiated clicks were 4x higher than organic help center searches. The bot was not replacing our documentation — it was making it accessible.

3. Weekend and Evening Coverage

Before the bot, weekend and evening inquiries waited until the next business day. After deployment, 39% of our bot conversations happened outside business hours. The bot resolved most of them immediately. The few that needed human follow-up were queued with full context for the Monday morning team.

Our weekend response time went from 40+ hours (Friday night to Monday morning) to 2 seconds. The impact on customer perception was significant — multiple users mentioned being surprised to get instant help on a Saturday night.

4. Feature Request Collection

An unexpected benefit: users who engaged with the bot were more likely to share feature requests. When the bot could not answer a question because the feature did not exist, it asked "Would this be something you'd want us to build?" and collected the request. We gathered 78 unique feature requests through the bot in 90 days — more structured and actionable feedback than we typically get through email.

How We Optimized Over 90 Days

Weekly Routine (2 Hours Every Monday)

Every Monday, someone on the team spent 2 hours reviewing the past week's bot conversations:

1. Review low-satisfaction conversations — conversations rated 3 or below. Identify what went wrong and fix the knowledge base or workflow.
2. Review abandoned conversations — conversations where the user left without resolution. Look for patterns in where users gave up.
3. Check handover conversations — conversations that escalated to humans. Could any of these have been handled by the bot with better knowledge base content?
4. Update the knowledge base — add new articles, update existing ones, remove outdated content.
5. Review analytics trends — resolution rate, satisfaction, handover rate week over week.

Major Optimizations Made

Week 3: Added integration-specific troubleshooting flows for our top 5 integrations (Shopify, WhatsApp, Slack, HubSpot, WordPress). These are multi-step troubleshooting sequences that walk users through common issues step by step, rather than dumping them with a single article.

Week 5: Rewrote our comparison content to be more balanced and honest. Early versions were too salesy ("LoopReply is better because..."). We shifted to objective comparisons that acknowledged competitor strengths while highlighting our differentiators. Paradoxically, the more balanced versions converted better.

Week 8: Added a "quick answers" layer for the 20 most common questions. Instead of running full RAG retrieval, these questions are matched against pre-written, optimized answers that are faster and more concise. This reduced average response time from 2.1 seconds to 1.4 seconds for the most common queries.

Week 11: Implemented multilingual support after noticing 8% of conversations were in non-English languages (primarily Spanish, Portuguese, and French). The bot now detects the user's language and responds accordingly, drawing from the same English knowledge base but generating responses in the user's language.

Performance Trajectory

The Numbers: Our Bot's Performance

After 90 days of operation, here is where our support bot stands.

Key Metrics

What the Team Does Now

Before the bot, our 3 part-time support people spent a combined 28 hours per week on support. Now they spend 8 hours — and those 8 hours are spent on:

• Complex technical troubleshooting that requires debugging
• Enterprise sales inquiries and custom implementation planning
• Bug report triage and escalation to engineering
• Weekly bot review and optimization (2 hours)
• Strategic customer success work (proactive outreach, health checks)

The nature of the work changed from reactive ticket processing to proactive customer success. Everyone on the team prefers it.

What This Taught Us About Our Product

Dogfooding did not just improve our support bot. It improved LoopReply as a platform. Here is what we shipped as direct result of building and running our own bot.

Product Improvements Shipped

1. Conversation context in RAG retrieval — follow-up questions now consider full conversation history (Bug 1 fix)
2. Configurable widget load delay — prevents intrusive mobile popups (Bug 2 fix)
3. Near-real-time knowledge base indexing — document updates reflected in under 60 seconds (Bug 3 fix)
4. Context-sensitive tone adjustment — bot adjusts formality based on conversation topic
5. Quick-answer caching — pre-written answers for most common questions, reducing response time
6. Multilingual auto-detection — bot responds in the user's language automatically
7. Feature request collection flow — template workflow for gathering user feedback through the bot
8. Improved analytics — added "conversation journey" view showing where users enter, navigate, and exit

Every single one of these improvements benefits all LoopReply customers. They were surfaced because we used our own product for real, high-stakes interactions — not because they appeared on a product roadmap.

Process Insights

Building our own bot also validated our recommended implementation process:

• Knowledge base is everything. The quality and completeness of the knowledge base determines 80% of the bot's performance. We recommend 30-50 documents minimum. We started with 187 and still found gaps.
• The first week is the hardest. Expect to make rapid fixes in the first week as real conversations reveal issues you did not anticipate. This is normal and healthy.
• Weekly reviews compound. Small weekly improvements (2-3 knowledge base updates, 1 workflow tweak) compound into dramatic performance gains over 3 months. Our resolution rate climbed from 62% to 79% through nothing but incremental weekly optimization.
• Proactive messages matter. Page-specific, contextual opening messages doubled our engagement rate compared to generic greetings. This is consistent with our customer data showing 12.4% vs 6.1% engagement rates.

Frequently Asked Questions

Is LoopReply's support bot still running?

Yes. You can interact with it right now on loopreply.com. It is the same bot described in this case study, continuously improved with weekly updates. What you see is what we built.

Do you still have human support?

Absolutely. The bot handles 79% of conversations, and our team handles the remaining 21% through the shared inbox. Every customer can reach a human at any time. We believe in the hybrid model — AI for speed and scale, humans for complexity and empathy.

What model does your bot use?

We use GPT-5 as our primary model with Claude Opus 4.6 as a secondary option. We test new models regularly through our own multi-model support feature. Our customers can choose from the same models we use.

How much time does the bot take to maintain?

Approximately 2 hours per week for the weekly review and optimization cycle. Major updates (new feature launches, pricing changes, new integrations) require additional one-time effort, typically 1-3 hours per update.

What would you do differently if starting over?

Three things: start with a staged rollout (20% traffic first, not 100%), rewrite documentation in plain language before uploading to the knowledge base (not after), and set up page-specific opening messages from day one. These are the three lessons that would have made our first week smoother.

Conclusion

Building our own support bot was one of the best decisions we have made as a company. Not just because it reduced our support workload by 71%, improved our response time by 99.9%, and raised our satisfaction score by 13%. Those numbers are great, but the real value was deeper.

Dogfooding made our product better. Every bug we found, every UX issue we experienced, every gap in our own documentation — these translated into product improvements that benefit every LoopReply customer. The conversation context fix, the tone adjustment feature, the quick-answer caching, the multilingual auto-detection — none of these would have been prioritized as quickly without the urgency of "our own support is broken."

It also gave us credibility. When a customer asks "Does this actually work?", we can point to our own bot. When they ask "What resolution rate should I expect?", we share our own numbers. When they ask "How long does setup take?", we share our own timeline.

If you are evaluating LoopReply, the bot on our website is your best demo. Ask it anything. Test it. Try to break it. What you see is what you get — the same platform, the same tools, the same experience your customers will have.

And if you are building a chatbot on any platform, the biggest lesson from our experience is this: the knowledge base is everything, the first week requires rapid iteration, and weekly optimization is what turns a good bot into a great one.

Start building your support bot with LoopReply — the same platform we use ourselves.