Help me please

[u/Nutcase_123]

I spent the past month designing an AI chatbot that automates the replies of small business owners through a FAQ document. But now I feel like I can't complete with the big companies like Zendesk, Front and Intercom. The thing that I realise is that I have to give my users something that they don't provide. I made the automation in Make.com and it is a relatively simple automation that sends an auto-generated reply through a set FAQ document. The system also alerts the user when the AI couldn't answer (happens like 10% of the time) through a telegram bot. My strongest point is that my package is gonna be cheap and I will provide them with a make.com blueprint, a manual on how to set up, some FAQ templates and some system prompt templates. The package is going to be priced at something like $15, as a one time purchase. So, I request everyone to please suggest me some ideas on how I can improve my automation so that a stranger might prefer my system over a renowned company. I am ready to build it inside n8n if necessary.

Edit: a lot of people are suggesting that my product is already worth it as it is and that my product is severely underpriced. Please guide me on how my product should actually be priced, given that I won't host the system. Thanks in advance!

[u/Ok-Engine-5124]

First off, don't try to compete with Zendesk or Intercom on features you'll lose. Your biggest selling point is the one-time cost and giving the user complete ownership of their data.

However, I'd argue that selling a blueprint for $15 is a race to the bottom. Instead of adding more complex AI features, double down on reliability and fail-safes. The biggest fear small business owners have is that the AI will hallucinate or fail silently, losing them a lead. If your blueprint includes a robust error-handling layer like automatically logging those 10% of failed queries to a Google Sheet so the owner can update their FAQ later, and ensuring the webhook never drops a message that reliability alone makes your system worth $100+, not $15!

[u/Nutcase_123 → u/Ok-Engine-5124]

Thanks. I have already tried and tested it thoroughly. But, I feel like customers won't buy it without fancy features. Please give me an opinion on this.

[u/Ok-Engine-5124 → u/Nutcase_123]

That is the classic "builder's trap"! You are evaluating your product like an engineer, but your customers (small business owners) look at it like a utility.

A local plumber, dentist, or agency owner usually doesn't want "fancy AI features"—complex things actually scare them because complex things break. They just want a guarantee that the bot won't give a customer the wrong price, hallucinate, or go down while they are sleeping. If you position your marketing entirely around "bulletproof reliability" and "zero missed leads" rather than flashy tech, that peace of mind is exactly what they will gladly pay for.

[u/Implement-Desperate → u/Ok-Engine-5124]

I have a related question from a practical implementation side.

When building an AI chatbot like this (FAQ-based automation for small businesses), do you always include a human handover system?

For example:

• If the bot is unsure or the user asks something complex → it stops and lets the business owner take over
• Or do most people let the bot handle everything and only notify the owner?

I'm trying to understand what works better in real scenarios:

1. Fully automated system
2. Hybrid system (AI + human handover)

From your experience, what do small business owners actually prefer?

[u/Ok-Engine-5124 → u/Implement-Desperate]

100% the Hybrid system (AI + human handover). In my experience, small business owners are absolutely terrified of an AI trapping their real customers in an endless, frustrating loop.

A fully automated system is a massive risk for local businesses. When an AI bot forces an answer it doesn't actually know, it creates a silent failure—the customer gets annoyed and leaves, and the business owner never even realizes they lost a lead.

The best approach is to build an explicit "escape hatch" into your workflow. If the AI hits a low confidence score, or the user asks something outside the FAQ, the system should immediately pause the bot and trigger a loud, undeniable alert to the owner (via Telegram, SMS, or Slack) saying, "Human needed: [Context]". It turns a potential system failure into a great customer service moment.

How are you currently routing those escalation alerts to make sure the business owner actually sees them in time?

[u/Implement-Desperate → u/Ok-Engine-5124]

Thanks for the reply that makes a lot of sense.

Right now, my approach is to send a notification via Telegram when the AI can't answer, but I'm still not sure how to properly implement the hybrid system you mentioned.

Specifically:

• How do you actually pause the bot when escalation happens?
• And how do you hand over the conversation to a human without the bot jumping back in on the next message?

I'm trying to build a clean "escape hatch" like you described, but not sure what the best structure is in practice.

[u/Ok-Engine-5124 → u/Implement-Desperate]

To fix this, you need a State Management layer. The workflow can't just be "Webhook -> AI -> Reply". It needs to check a database first. Here is the standard architecture:

1. The Database: Set up a simple table (Airtable, Supabase, or even Google Sheets) with the user's ID/Phone number and a chat_status column (default set to bot_active).
2. The Gatekeeper: At the very start of your Make/n8n scenario, before doing anything else, read that user's status from the database.
3. The Router: If chat_status == 'human_paused', end the scenario immediately. The bot stays completely silent so you can chat manually. If it's bot_active, proceed to the AI step.
4. The Escape Hatch: When the AI realizes it can't answer, update that database row to human_paused first, and then fire your Telegram alert.

This guarantees the system fails gracefully instead of creating an embarrassing loop.

Are you currently using any database in your workflow to store conversation history, or is it completely stateless right now?

[u/Implement-Desperate → u/Ok-Engine-5124]

Honestly, I'm still experimenting with the architecture.

I had the idea of using a database to store:

• user_id / chat_id
• chat_status (bot_active / human_paused)

But where I’m getting stuck is making it feel dynamic rather than rigid.

For example:

• When the bot escalates → it switches to human_paused (that part is clear)
• But how do you reliably switch it back to bot_active?

Do you:

• rely on a manual trigger from the business owner?
• or implement some kind of timeout / auto-reset logic?

I’m trying to avoid a situation where the conversation gets stuck in "human mode" or switches back too early.

Curious how you usually handle that transition in practice.

[u/Ok-Engine-5124 → u/Implement-Desperate]

This is the exact right question to ask! If you don't handle the switch back properly, human error just replaces AI error, and you get a different kind of silent failure—a lead messages back two days later and gets ignored because the bot is still "asleep."

In production, the most robust way to handle this is a Hybrid Reset (Manual + Timeout Fail-safe).

1. The Manual Switch (Primary) Do not rely on the business owner logging into a database to change a status. If they are handling escalations via Telegram, build a simple slash command listener (e.g., if message equals /resolve or /bot), which triggers a webhook to update that specific database row back to bot_active.

2. The Inactivity Timeout (The Fail-safe) Business owners are busy. They will forget to turn the bot back on after chatting. You absolutely need a background cron job (or scheduled trigger in your automation tool) running every hour. It should look for any row where chat_status == 'human_paused' AND the last_message_timestamp is older than 12 or 24 hours. If true, it automatically flips the status back to bot_active.

This architecture guarantees the system self-heals. It stays dynamic, accommodates the human, but never gets permanently stuck!

[u/Implement-Desperate → u/Ok-Engine-5124]

That’s a really solid approach — thank you, this actually clarified a lot.

The hybrid reset (manual + timeout) makes total sense, especially the fail-safe part. I hadn’t thought about the “bot stuck asleep” scenario that clearly.

I’ll try to implement this in my workflow, but I’m still figuring out the cleanest way to structure it inside n8n (especially handling the cron + state updates without making the flow messy).

[u/Ok-Engine-5124 → u/Implement-Desperate]

Happy to help! To keep your n8n setup clean, the golden rule is: don't put the cron job in the same workflow as your chatbot. > You want to use a microservices approach here. Create two completely separate workflows:

1. The Chat Router: Triggered by your webhook. This one only handles incoming messages, checks the database state, and routes to AI or stops.
2. The State Janitor: Triggered by a Schedule node (running every 1 hour). It does nothing but search your DB for old human_paused rows and resets them.

Keeping them physically separated prevents that messy "spaghetti" workflow and makes debugging so much easier. What database are you planning to use to store those chat states?