When I started building OctoBot, I had one simple observation:
Most support tickets are boring.
Not boring for the customer — they genuinely need help. But boring for the person answering them, because they've answered the exact same question 200 times before.
"Where is my order?"
"What are your shipping delays?"
"How do I reset my password?"
"Can I return this item?"
If you run an e-commerce store or a SaaS product, you know this list by heart.
So I asked myself: why is a human spending 3 hours a day on this?
The technical approach
OctoBot is built around a simple architecture:
Intent classification first — before generating any response, the bot classifies the incoming message into one of N intent categories. If confidence is below threshold, it escalates to a human agent. No hallucinations on edge cases.
Context injection — for order tracking, the bot queries the e-commerce backend (Shopify, WooCommerce, custom APIs) in real time and injects the actual order data into the response. Not a generic "please check your email" — the real tracking number, the real delivery date.
Escalation logic — anything the bot can't handle with high confidence gets flagged and routed to a human with a summary of the conversation. The human picks up with context, not from scratch.
Learning loop — every time a human agent overrides the bot, that becomes a training signal. The model improves on real production data.
What I got wrong in v1
The first version tried to handle everything with a single LLM prompt. It worked okay on simple cases but fell apart on anything slightly ambiguous.
The lesson: LLMs are great at generation, terrible at reliable classification without structure.
v2 added an explicit intent router before the LLM response layer. Classification accuracy went from ~71% to ~94% on our test set. Escalation rate dropped by half.
The stack
Backend: Node.js + Express
NLP layer: Fine-tuned classification model + GPT-4o for response generation
Integrations: REST webhooks, Shopify API, WooCommerce API, custom CMS connectors
Frontend widget: Vanilla JS embed, < 8kb gzipped, no dependencies
Infrastructure: Railway for the API, Supabase for conversation logs
Kept it deliberately simple. No Kubernetes, no microservices. It's a product, not a distributed systems demo.
Results after 30 days in production
Across our current users:
Tickets handled automatically: 68%
Average response time: < 10 seconds
Human escalation rate: 32%
Customer satisfaction score: +12% vs. pre-OctoBot baseline
The 32% that escalate to humans are genuinely complex — disputes, custom requests, frustrated customers who need empathy, not automation. That's where humans should be spending their time.
The business model
I wanted to make this accessible to small teams, not just enterprise.
Free tier — create your first bot, test it on your site, no credit card.
35€/month — unlimited bots. Built for agencies that want to resell this to their clients or deploy across multiple projects.
A lot of web agencies are picking this up as an add-on to their existing offer. They build the site, they deploy the support bot, they add 35€ to the monthly retainer. Everyone wins.
What's next
Working on:
Native Slack / Teams integration for internal helpdesks
Voice support (WebRTC)
Analytics dashboard with ticket trend detection
If you're building something in the support automation space or have feedback on the architecture, I'd love to hear from you.
👉 octobot.fr — free to try, no setup fees.
Top comments (0)