EN
Ihor Nikolenko- The Script on Paper First, the Bot Second
- Step 1: The Bot in Telegram and the Trigger in n8n
- Step 2: Conversation Memory — Where the Bot Tracks Which Question You're On
- Step 3: Scoring and the Decision
- Step 4: Handing Off to a Human — A Summary, Not Just a Contact
- Limits: What the Bot Doesn't Do
- What to Build After the First Version
- The Short Version
- Frequently Asked Questions
A lead comes in at 11:40 p.m. The manager will see it in the morning, write back at ten, and by then the person has already talked to two of your competitors, whose bots answered in a second. Or a different picture: leads pile up, the manager spends half the day making calls just to ask "so what exactly are you interested in," and half of those people aren't even your customers — wrong budget, wrong region, wrong task.
One construction fixes both problems: a Telegram bot that asks a handful of the right questions right after someone reaches out, scores the answers, and hands the manager not just a "contact," but a ready-made summary: who, what, when, how good a fit. In the morning, the manager calls in prepared, and only calls the people actually worth calling. I've built bots like this for the club and for client projects, and the discovery is always the same: the value isn't in the technology, it's in the question script.
This guide goes from a script on paper to a working bot in n8n: which questions to ask and why, how to store conversation state, how to score a lead, how to hand off to a human, and where the bot should go quiet. No code required.
The Script on Paper First, the Bot Second
Qualification answers one question: is it worth the manager's time to reach out to this person right now. Three to five clarifying questions are usually enough to answer it. More, and the person gets tired and leaves; fewer, and the manager is back to calling blind.
Here's how I put a script together. For every question: why it's there, and how to score the answer.
| The bot's question | What it establishes | How it's scored |
|---|---|---|
| What exactly do you need? (buttons for your service lines) | Whether this is your kind of job at all | Your service line is a plus; "other" gets clarified or handed off to a human |
| When do you need it? (now / this month / just researching) | Urgency | "Now" is the highest priority for a call |
| What's the approximate budget? (ranges as buttons) | Fit with your pricing | Below the minimum gets a polite reply, no call |
| Who makes the decision? (me / together with someone / just passing this along) | Whether we're talking to the actual decision-maker | "Me" is a plus; "passing along" means send materials, don't call |
| What's the best way to reach you? (call / here on Telegram / email) | Channel and timing | Passed to the manager as an instruction |
Two rules for the questions. First: answer options as buttons, not free text, wherever possible. Buttons are faster for the person and give the bot clean values that are easy to score. Second: no question exists "for statistics." If the answer doesn't change what the manager will do, the question is unnecessary.
Live through this script for a week by hand: the manager asks these exact questions in chat and records the answers. You'll see which questions annoy people, which answers don't fit the buttons, and what the manager actually needs to know before calling. Only after that comes the bot.
Step 1: The Bot in Telegram and the Trigger in n8n
In Telegram, open BotFather, send the /newbot command, give the bot a name and a handle, and get a token back. The token is the key to your bot; it belongs inside n8n as credentials, and nowhere in a chat, ever. While you're in BotFather, set a description and a welcome message: a person should understand within a second that this is the company's assistant, and what happens next.
In n8n, create a workflow with a Telegram Trigger node, plug in the bot's credentials, and select the "message" event. Now every message sent to the bot triggers the workflow, and the data includes the text, the chat ID, and the username. Full details on what the bot can do live in the official Telegram Bot API documentation; for this guide, it's enough to know that the bot can receive messages, send replies, and show buttons.
One detail that pays off later: a link to the bot can carry a start parameter, like t.me/yourbot?start=site_header. When someone clicks it, the bot receives that parameter in its first message, so you know exactly where they came from — the site, an ad, a post. Different links for different sources, and qualification instantly doubles as analytics too.
Step 2: Conversation Memory — Where the Bot Tracks Which Question You're On
This is the part where first attempts usually fall apart. Every message re-triggers the workflow from scratch, and on its own, the bot has no memory that a person has already answered two out of five questions. You need a place that holds state for each chat: the current question number and the answers so far.
The simplest place for this is a spreadsheet: Google Sheets, or n8n's own built-in data table. One row per chat, with columns for chat ID, name, source, step, answer 1, answer 2, and so on, score, and status. The workflow starts with a node that looks up a row by chat ID: no row means a new person — create one and ask the first question; a row exists — read the step, write the answer into the right column, and ask the next question.
Next comes a Switch node, or a series of IF nodes, that picks which question to send based on the step number. Every branch ends with a Telegram node using the "send message" action, with buttons: the node's settings let you define buttons as a keyboard of options, and a tap arrives at the bot as regular text. That's the whole mechanism of the dialogue: read the state → record the answer → ask the next question → update the state.
One important detail: a person might type something instead of tapping a button. Build in an "answer not from the options" branch: politely repeat the question with the buttons once, and on the second miss, just record the text as-is and move on. A bot that endlessly repeats "please pick an option" is the fastest way to lose someone.
Step 3: Scoring and the Decision
Once every answer is recorded, a separate branch calculates the score. It's simple arithmetic in a Set node or an expression: every answer carries a weight from your script table, and the sum is the lead's score. For example, "now" and "I'm the decision-maker" add more than "just researching" and "passing this along." There are two thresholds: above the top one, an urgent call; between the two, the regular queue; below the bottom one, materials and a polite close, no call.
The weights and thresholds aren't permanent. After a month, check which high-scoring leads never became customers and which low-scoring ones did, and adjust. That's the only way to keep the scoring honest: the indicator has to show fact, not your assumptions about the customer.
This is also a good spot to bring in a language model — not for the dialogue itself, but for one single step: summarizing free-text answers into two sentences for the manager, or pulling a city name or product name out of the text. The model only receives the text of the answers and returns something structured. That's safe, because it never promises anything to the customer and never makes any decisions.
Step 4: Handing Off to a Human — A Summary, Not Just a Contact
The most important node in the workflow is the message to the manager. Not "new lead, phone number XYZ," but a summary:
- who they are and where they came from (source from the start parameter);
- what they need, when, what budget, who decides — the button answers;
- the score and a recommendation: "call today" / "queue" / "send materials";
- the best way to reach them, and a link to the chat with them.
At the same time, that same row with every field goes into the CRM, or just stays in the spreadsheet with the status "handed off." And the customer gets one last message from the bot: what happens next, who will reach out and when. Uncertainty after submitting a lead kills more deals than price does.
After that, the bot goes quiet. If the person writes again, the message just gets forwarded to the manager, with no workflow processing. The bot did its job; a human takes it from there.
Limits: What the Bot Doesn't Do
- It doesn't quote prices outside the range buttons, and it doesn't promise timelines. Anything that resembles a commercial term comes from the manager.
- It doesn't argue and doesn't try to retain anyone. If a person writes "not interested" or "changed my mind," the bot thanks them and closes the conversation, and the spreadsheet status is "declined."
- It doesn't hide that it's a bot. The first message states it plainly: this is the company's assistant, a few questions, then a human.
- It doesn't collect anything extra. Only what's needed for the manager's decision; a single sentence about data processing, with a link to the policy, comes at first contact.
- It doesn't go silent when it breaks. A separate error workflow notifies you if the main one fails, and the person gets "passing you to a manager," so they're never left without a response.
What to Build After the First Version
Once the bot has run for a week and the manager says the summaries genuinely help, natural extensions start to suggest themselves: a reminder to the manager if a "call today" lead hasn't been picked up within two hours; a weekly report on sources and scores; sending a "qualified lead" event to your ad accounts, so the algorithms train on real leads instead of clicks. All of these are separate, small workflows sitting alongside the main one.
You don't have to build this from scratch. The n8n Telegram Traffic Processor is a ready-made foundation for exactly this kind of setup: taking in Telegram traffic, processing it, and passing it along — you just plug in your own question script and weights. And if the bot is part of a bigger launch, one that also needs a site, a funnel, and people to handle the qualified leads, that's what I do in launch support: not a bot for its own sake, but systematic sales, where the bot is just one link in the chain.
The Short Version
- Qualification is three to five questions, each of which changes what the manager will do; answer options as buttons.
- Run the script by hand for a week first, then build the bot: that's how you see which questions annoy people and what the manager is actually missing.
- BotFather gives you a token, n8n's Telegram Trigger fires the workflow on every message; the start parameter reveals the source.
- Conversation state lives in a spreadsheet: one row per chat, the step, and the answers; the workflow reads the state, records the answer, asks the next question.
- The score is the sum of answer weights against two thresholds; the weights get revised against actual deals.
- The manager gets a summary with a recommendation, the customer gets an honest "what happens next"; after the handoff, the bot goes quiet.
- The bot doesn't quote prices, doesn't argue, doesn't hide being a bot, and doesn't go silent when it breaks.
Frequently Asked Questions
Doesn't a bot scare people off compared to a live response?
What scares people off is a bot pretending to be human or asking ten questions. An honest assistant with three to five button-based questions and a promise of "a human comes next" reads as speed, not as a barrier.
Can I build the same thing without Telegram, in a site chat widget or WhatsApp?
The mechanics are identical: a message trigger, a state spreadsheet, questions, scoring, handoff. Telegram is convenient because of its open API and n8n's ready-made node; other channels need their own connections.
Does a bot like this need a language model?
Not for a button-based script, and the bot is more predictable without one. A model is useful for one specific step — summarizing free text for the manager — and for more complex conversations, once the script itself has already been tested.
Where should I store customer data — a spreadsheet or a CRM?
A spreadsheet is enough, and transparent, to start with. Once volume grows or multiple people work with the data, move to a CRM: one node in the workflow instead of writing a row. A data-processing policy is needed either way.
