Singuard Home Blog Contact eTrader eTrader for Businesses eTrader for Traders Broker Broker CRM Live Demo Prop Firm Prop Firm CRM Live Demo
Scalegram

Handing a Conversation to a Human.

Customers do not mind talking to a bot. They mind a bot that will not admit it is out of its depth and keeps answering anyway.

Roman Onta, Executive Director, SINGUARD By August 28, 2026 6 min read

Every assistant has a boundary. The interesting design question is not whether it exists but what happens when a conversation reaches it. An assistant that guesses past the boundary damages the account it is attached to. An assistant that hands over cleanly is often rated more highly than a human-only desk, because the first answer arrived in seconds and the hard question still reached a person.

The triggers worth setting

Four categories cover most of it. Anything involving money or access: refunds, discounts, granting entry to a paid group, changing what someone has already bought. Anything the fact store does not answer, where the alternative is invention. Anything where the customer is upset, which a model can detect and should not attempt to resolve on its own. And a direct request to speak to a person, which should always be honoured immediately and without a negotiation.

The last one gets argued about. Some operators want the bot to make one more attempt before passing the chat on. That attempt reads as obstruction to the person asking, and the cost of it is out of proportion to the handoffs it saves.

Acting versus asking

Handoff is one of two mechanisms, and they solve different problems. Handoff moves the conversation to a person. An ask me checkpoint keeps the assistant in the conversation but stops it before an action, asking the operator in their own Telegram to approve first.

Use checkpoints for things the assistant can do correctly but should not do alone: sending an invite, applying a discount, marking something paid. Use handoff for things it cannot do correctly at all, like negotiating with an angry customer. Mixing them up produces either an assistant that pesters you about routine replies or one that acts alone on decisions that needed a person.

The message the assistant sends when it hands over matters more than the routing. Say a person is coming and roughly when. Do not promise a timeframe the team cannot meet, and do not leave the customer looking at silence.

What the person picks up

Here is where Scalegram works differently from most tools in this category. It stores no message content at all. There is no saved transcript for a colleague to read, because conversations are never saved, only contact recency and a link straight into the real Telegram chat.

So the handoff hands over a link, not an archive. The person opens the actual conversation in Telegram and reads it there, where it has always lived and where the customer can see them typing. In practice that is faster than reading a mirrored transcript in a second window, and it removes an entire class of privacy exposure: a copy of your customers' words sitting in a vendor's database.

The trade is real and worth stating. You cannot search old conversations inside the CRM, and you cannot run analysis over what customers said. Businesses that want a searchable archive of everything should know that before choosing this. Businesses that would rather not create that archive at all get exactly what they wanted.

Routing and who is on the hook

A handoff with no owner is a lost conversation. Decide who receives them, and decide it per bot rather than globally if different bots serve different audiences. Team members carry permissions per area, read, add, write and delete, so a handoff can reach someone who can actually resolve it rather than someone who can only look.

Set a second rule for what happens if nobody picks it up. An unanswered handoff is worse than no handoff, because the customer was explicitly told a person was coming. Whether that is an alert to the owner or a rotating duty, pick one and write it down. Where handoffs sit alongside stages and tags is covered in lead management.

Read the queue, do not just clear it

The handoff queue is the best diagnostic the setup produces. Sorted by reason, it tells you which gaps in the fact store cost you the most conversations and which questions genuinely need a person forever.

Handle it in two passes each week. First, resolve the open ones. Second, for each closed one, decide whether the assistant should have been able to answer it. If yes, the missing fact goes in immediately, which is the loop described in facts and snippets. If no, leave it and stop treating it as a defect.

The number that is not the goal

Handoff rate is worth watching and is a terrible target. Drive it to zero and you have built an assistant that answers everything, including the things it should not have touched. The number that matters is what happened after each handoff: was it resolved, how long did the customer wait, and did the conversation continue.

A setup with a moderate handoff rate and fast resolution beats a setup with a low rate and a trail of confident wrong answers, every time. The first loses a little automation. The second loses customers, and does it quietly enough that the dashboard still looks healthy.

"The handoff is the feature people actually rate you on. Nobody remembers the twelve questions the bot answered. They remember the one it should have passed on and did not."

— Roman Onta, Executive Director, SINGUARD

Key Takeaways

Frequently Asked Questions

What does a colleague see when a conversation is handed over?

A link into the real Telegram chat. Scalegram saves no message content, so there is no mirrored transcript to read, only contact recency and the jump back into the conversation itself.

Should the bot try once more before passing on a request for a human?

No. A direct request for a person reads as obstruction when it is deflected, and the goodwill lost outweighs the handoffs saved.

Is a low handoff rate a good sign?

Not on its own. A rate near zero usually means the assistant is answering things it should have escalated. Resolution time and outcome after handoff are the better measures.


About the Author

Roman Onta, Executive Director, SINGUARD
Roman Onta Executive Director, SINGUARD

Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.

Your Own Trading Firm, Live in 24 Hours.

SINGUARD builds the technology behind brokers and prop firms: trading platform, CRM, client portal and payment rails, one bundle, one predictable price. Book a call and see it working, or keep reading the guides.

More in Scalegram