Manage Multiple Telegram Bots From One Panel

The moment you run a second Telegram funnel, the tooling question changes. A single bot is easy: one BotFather token, one list of subscribers, one welcome message. Two bots for two brands, or ten bots for ten clients, is a different problem. You need the accounts kept apart, the content kept apart, and the people kept apart, without logging in and out of ten separate dashboards to check whether yesterday's broadcast actually landed.

mySkua is built as a multi-tenant panel for exactly that shape of work: one login, a list of bots, and hard separation between them.

Why agencies and multi-brand teams need separation

The common failure mode when you manage many bots with single-bot tooling is contamination. A broadcast written for Brand A goes to Brand B's list. A promo code from one client's campaign shows up in another client's welcome message because someone edited the wrong text. A freelance copywriter who was hired to rewrite one onboarding flow can also see every subscriber in the account.

None of those are exotic edge cases. They are what happens when the tool has one global namespace and you put many businesses inside it. The fix is not discipline, it is structure: the bot has to be the boundary, and everything beneath it — subscribers, texts, campaigns, drips, categories, languages, analytics — has to belong to exactly one bot.

This matters for three groups in particular:

• Agencies running acquisition funnels for clients who must never see each other's data.
• Multi-brand operators running the same playbook for several properties or geos.
• Affiliates running parallel offers, where one bot per vertical keeps the messaging honest and the reporting readable. That pattern is covered in more detail in our guide to running an affiliate marketing Telegram bot.

Isolated subscribers and content per bot

In mySkua every bot is its own workspace. When you switch bots in the panel, you switch the entire dataset with it:

• Subscribers belong to one bot. Someone who started Bot A is not on Bot B's list, and no broadcast from B can reach them.
• Bot Texts — the onboarding messages, per language, with their media and inline buttons — are per bot.
• Languages are per bot. One bot can serve Portuguese and Hungarian, another English only.
• Categories (the interest a subscriber self-selects, e.g. Sport or Casino) are defined per bot, along with each category's own welcome offer.
• Campaigns, auto-messages and broadcasts are scoped to the bot they were created in.
• Sources and tags from deep-link payloads attach to subscribers inside that bot only.

The practical effect is that a mistake stays local. If you write a broadcast in the wrong tab, the recipient count in front of you is the wrong bot's count, and the numbers usually give it away before you send. You cannot accidentally address a list that lives in another workspace, because there is no way to select it.

Reusing campaign structures across bots

Isolation is the right default, and it has an obvious cost: the second bot does not inherit the first one's work. Be clear about what is genuinely reusable here. What travels between bots is the structure — the shape of the funnel and the conventions you use — not a shared object that syncs across workspaces.

That is still most of the value, because the shape is what took you the longest to get right. Every bot in mySkua uses the same building blocks, so a funnel you have proven once becomes a checklist you can execute again:

• The same onboarding order: /start, language pick, optional category pick, optional channel-subscription gate, welcome offer.
• The same campaign anatomy: a code, a per-language message, media, inline URL buttons, an active window, a “new users only” flag and one-time activation per subscriber.
• The same drip skeleton: an auto-message at a fixed delay after join, targeted by language, source, tag or category.
• The same naming convention for deep-link payloads, so ?start=tiktok_oct_a means the same thing in every bot you run.

Keeping those conventions identical across bots is what makes the next section possible. If Bot A calls a source ig_story and Bot B calls it instagram-stories , your portfolio view is guesswork.

Team roles: owner, admin, editor, viewer

Access is granted per bot, not per account. You invite a person to a specific bot and give them one of four roles:

• Owner — full control of the bot, including its token and its team.
• Admin — day-to-day operation of that bot.
• Editor — content work: texts, campaigns, messages.
• Viewer — read access, for a client or a stakeholder who wants the numbers without the ability to change anything.

Because the grant is scoped to one bot, a contractor added to a single client's bot sees that client and nothing else. The viewer role is the one agencies tend to use most: it lets you hand a client a live view of their own funnel instead of exporting a monthly slide, without any risk that a curious stakeholder fires a broadcast.

Comparing performance across your portfolio

Analytics in mySkua are scoped the same way everything else is: per bot. You get subscriber growth, daily active users, retention cohorts, campaign activations and delivery stats for the bot you are looking at. There is more on what each of those measures in Telegram bot analytics.

Comparing a portfolio, then, is a discipline rather than a magic button — and the discipline is naming. Because campaign codes, sources and categories are yours to define, you can make the same funnel stage legible in every bot:

• Use one payload vocabulary across bots so fb_, tt_ and tg_ prefixes mean the same channel everywhere.
• Keep campaign codes structured — channel, month, variant — so activations are comparable bot to bot.
• Watch the same three numbers per bot: joins by source, activation rate on the welcome offer, and cohort retention at day 7. Those are the ones that expose a bot that is quietly underperforming.

The comparison you should trust most is a bot against its own past. Traffic mix, language and offer differ enough between bots that a raw side-by-side of activation rates usually says more about the traffic than about the funnel.

Onboarding a new client bot quickly

Adding a bot is the operation an agency repeats most, so it is worth having a fixed sequence. A workable order:

• Create the bot in BotFather and add its token to the panel as a new bot in your account.
• Add the languages that bot will serve, then write the onboarding texts for each one. The bot auto-detects the Telegram client language and the subscriber confirms it, so every language you add should be complete before you drive traffic.
• Decide whether this bot needs a category step and a channel-subscription gate. Both are optional per bot, and both add friction — use them when the segmentation or the channel growth is worth it.
• Set the welcome offer, per language and, if you use categories, per category.
• Create one campaign per traffic source with its deep link, and build the first drip: one auto-message at a short delay for people who did not activate.
• Invite the client as a viewer, and your operator as an editor or admin.

Run the whole flow yourself in Telegram before the first ad goes live. Onboarding bugs are almost always missing translations or a gate pointing at the wrong channel, and both are obvious on a real device in under a minute.

Operational hygiene when running many bots

• Name bots for humans, not for BotFather. The panel label should say which brand and which market, because that label is what stops a broadcast going to the wrong list.
• Check the recipient count before every send. It is the cheapest confirmation you are in the right bot.
• Keep active windows tight on campaigns. An expired offer that is still reachable through an old deep link is a support problem in every bot at once.
• Prune team access when engagements end. Per-bot roles make this quick, but only if someone actually does it.
• Expect drips to shed subscribers. Auto-message delivery retries are bounded and people who block the bot are dropped, which is correct behaviour — read a falling deliverable count as a signal about the content, not as a bug.
• Write down the conventions. A one-page internal doc of payload prefixes and campaign-code format is what keeps bot number nine as readable as bot number one.

Common questions

Can subscribers be moved or merged between bots? No, and that is deliberate. A subscriber relationship belongs to the bot they started, which is also what the person consented to when they pressed Start.

Does one person need separate accounts for separate clients? No. One mySkua login lists every bot you have been granted access to, at whatever role you were given on each.

How does this compare with other tooling? We keep an honest overview in our roundup of Telegram bot platforms, including where general-purpose chatbot builders are the better choice.

Getting access to mySkua

mySkua is currently in a private, invite-only beta, so accounts are opened by request rather than self-serve. If you are running more than one Telegram funnel — for clients, brands or offers — join the waitlist and tell us how many bots you operate and what the funnels look like. Teams already managing a portfolio are the ones we are onboarding first, because that is the workload the panel was built around.

You can request access from the mySkua homepage.