Two ways to build a sales bot. The old way is a decision tree: press 1 for pricing, press 2 for support, and every human sentence that does not fit falls off the edge. The new way is to hand everything to a language model and hope. Both fail in a paid funnel, the first because people do not talk in menus and the second because a model with no boundaries will eventually agree to something you cannot deliver.
Scalegram's flows sit between the two. You build a flow out of blocks. Each block defines a goal, what the assistant may say while pursuing it, and the condition that ends it. Inside a block the model writes freely in the client's own language. Between blocks it does what you decided.
What a block is made of
A block carries an objective in plain language, the facts it is allowed to state, and an exit condition. Ask for the trading experience level. Answer questions about what the community includes. Collect the account number. Confirm the deposit before granting the invite. The assistant works towards that objective, handles whatever the person actually says on the way, and moves on when the condition is met rather than after a fixed number of turns.
Because the exit is a condition and not a step count, a client who answers three questions in one message skips three blocks at once. That is the behaviour a decision tree can never produce and the reason people stop feeling like they are filling in a form.
The blocks most funnels actually use
An opening block that greets and reads intent. A qualifying block that learns what the person wants and whether you can serve them. An answering block that handles objections from the facts you wrote, including price. A collection block for the thing you need, usually an account identifier or an email. A verification block that checks a fact against a connected system. A handover block that stops and pulls in a human. A closing block that sends the link or the invite once everything required is true.
Facts are shared rather than retyped into every block. Your pricing lives in one place, and when it changes the whole flow tells the truth immediately. This is the same discipline as writing the assistant's playbook, applied at the level of a single stage of the conversation.
Where improvisation stops
Three hard boundaries, and none of them is a suggestion in a prompt.
The first is granting. Access to a paid group, a discount, an upgrade, anything that costs you money or reputation, does not happen because the model was persuaded. It stops at a checkpoint and asks you in your own Telegram, and you tap yes or no. The mechanism is described in ask-me checkpoints.
The second is verification. A block that needs a funded account asks the connected integration rather than trusting a screenshot or a number typed into a chat. Where a broker exposes an affiliate API, the account is checked against the accounts registered under your link before the flow proceeds.
The third is conduct. The assistant is hard-blocked from flirting, from romantic or intimate framing of any kind, and from promising that a person will make money, that a payout is certain, or that anything will be relayed to a human who has not agreed to it. In a trading niche this is not decoration. A bot that gets warm with a client and implies a return has produced a financial promotion nobody reviewed.
Language, and why it is not a setting
The assistant answers in the language the message arrived in. Not a dropdown you set once, not a guess from the client's country. If a Portuguese speaker writes in English and later switches, the flow follows them. If the person explicitly asks to be answered in a particular language, that is pinned for the conversation rather than being re-decided on every message. The blocks do not change; only the words do.
Building one without wrecking a live funnel
Start with three blocks, not fifteen. Greet, qualify, hand over. Run it on real traffic for a few days and read where people stalled, then split the block that failed instead of adding new ones everywhere. The most common mistake we see is a flow with a block for every possible question, which produces an assistant that interrogates people.
Keep the facts short and true. A model given four sentences of accurate pricing outperforms one given two pages of marketing copy, because the marketing copy contains claims you did not intend it to repeat.
A flow is not a compliance review. If your market regulates what may be said about a financial product, write the permitted wording into the facts yourself and have it checked by whoever normally checks your marketing. The software will repeat what you gave it.
Handover as a block, not an emergency
The best flows have a handover block that gets used often and without drama. It triggers on the questions you listed, on keywords you chose, and on the assistant simply not being confident. It says something plain, flags the conversation, and stops. An assistant that never hands over is not a good assistant, it is one that has been told to keep talking past the edge of what it knows.
The number worth watching in the first fortnight is where handovers cluster. Three handovers a day on the same question means the answer belongs in a block's facts. Handovers scattered everywhere usually means the facts are too long and the model is losing the thread.
What happens after the conversation
Nothing of what was said is kept. The flow leaves behind the outcome: the stage moved, the tag applied, the account number stored on the contact, the purchase claimed. That constraint is set out in never storing conversations, and it is why a flow should write its important findings to fields rather than assume the transcript will be there tomorrow. There is no transcript tomorrow.
"A block is a leash with a job attached. The model can say anything that gets it to the goal, and it cannot do the one thing that would cost you money without asking you first."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Each block carries an objective, the facts it may state and an exit condition, so a client who answers everything at once skips ahead instead of being marched through steps.
- Facts live in one place and are shared across blocks, so a price change updates the whole flow at once.
- Granting anything of value stops at a checkpoint in your own Telegram, and claims like a funded account are checked against a connected integration rather than believed.
- The assistant is hard-blocked from flirting and from promising outcomes, and it replies in the language the message arrived in.
Frequently Asked Questions
Do I need to write code to build a flow?
No. Blocks are configured in plain language: the objective, the facts the assistant may use, and the condition that ends the block. The writing is closer to briefing a new salesperson than to programming.
Can the assistant give someone access to a paid group on its own?
No. Anything that grants access or costs you money stops and asks you in your own Telegram, and it proceeds only after you tap yes.
What stops the model from inventing a promise?
Two things. It answers from the facts you wrote into the block rather than from general knowledge, and a hard block prevents promises about earnings, guaranteed outcomes or relaying something to a human who has not agreed to it.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.