Compose once, filter the audience, watch the recipient count move, and send — then read what actually got delivered. Broadcasts in mySkua are built for bot subscriber lists, not for channel posts.
Most people searching for telegram broadcast software already have a channel and know how to post in it. Their real problem is different: they have a bot with thousands of individual subscribers who each pressed /start, and they want to reach a subset of those people in a private chat, in the right language, with a link attributable back to the send.
That is a different mechanism. A channel post is one object seen by many; a broadcast is one API call per recipient, each with its own chat and its own delivery result. It costs more to send and has to be paced, but it buys three things a channel post cannot: per-person targeting, per-person language, and a delivery record you can audit. The broadcast message glossary entry lays out the terms if the distinction is new.
mySkua has two send paths. This page covers the manual one-off path and its scheduled sibling; the automated path — messages triggered by how long ago somebody joined — is drip automation, covered at the end.
A broadcast audience in mySkua is assembled from four filters, applied together as an AND:
instagram_nov, affiliate_7, whatever you encoded. You can select several sources at once; they combine as an OR, so one send can address every paid channel and skip organic traffic.An untouched filter narrows nothing, so "everyone" is the default and every restriction is deliberate. The filter set is stored on the broadcast record along with the tag mode, which matters more than it sounds: weeks later, when a send looks unusually good or unusually bad, you can still see which slice of the list received it. For how these attributes reach subscribers in the first place, see audience segmentation.
Every filter change recalculates the recipient count against the current subscriber table and shows it next to the compose form. This is the single most useful guard rail in the whole screen. A tag filter left in ALL mode when you meant ANY does not produce a warning — it produces a recipient count in the dozens where you expected the whole list, and you see that before you commit, not in the delivery report.
Alongside the count is a Telegram-faithful preview: the body as Telegram will render the HTML, the attached media, and the inline keyboard as it will appear in the chat. Preview matters here because you cannot quietly edit a message already sitting in several thousand private chats the way you can edit a channel post. The confirmation step then restates the audience size, so Send is a decision about a number you have seen twice.
Three states block a send outright, by design: a paused bot, a bot with no Telegram token configured, and a bot in read-only mode where delivery is deliberately owned elsewhere.
A broadcast is not limited to plain text. Attach a photo or a video, or force any attachment to send as a file when you want the document treatment rather than an inline player. Uploaded media is converted to a Telegram file_id once, before the send loop starts, then referenced for every recipient rather than re-uploaded thousands of times.
Message text supports Telegram's HTML subset — bold, italics, underline, strikethrough, links, inline code, preformatted blocks, blockquotes and spoilers. Anything outside that subset is stripped before sending, because Telegram rejects the whole message on a malformed tag and a rejected message is a failed send for every single recipient.
Inline URL buttons sit under the message, and in a lead-generation funnel that is usually where the conversion happens: the copy persuades, the button carries the offer link. Buttons are stored with the broadcast, so a replayed send keeps the same keyboard.
A scheduled broadcast is the same message object with a recurrence attached. You pick a schedule type — daily, weekly with a weekday, or monthly with a day of the month — a send time, and a time zone from the IANA list (Europe/Lisbon, America/Sao_Paulo, and so on). The next fire time is calculated from those inputs and stored on the record, then updated after each run.
Storing an explicit time zone rather than a UTC offset is deliberate. Offsets drift with daylight saving: a 20:00 send configured as UTC+1 in January silently becomes 19:00 in July. Naming the zone keeps "20:00 local for my audience" true all year.
Scheduled broadcasts carry per-language message bodies, so one weekly digest serves a multilingual list without being duplicated three times. They take the same targeting attributes as one-off sends, and each can be paused without being deleted — useful for a promo cadence you want back next quarter.
Every one-off broadcast is written to history with the numbers that matter: total audience, sent, failed, and a status of sent, partial or failed, plus who pressed the button and when. The per-recipient detail list keeps the actual error text Telegram returned, which is the difference between "the send underperformed" and "the send was rejected for a malformed tag".
The pattern worth watching is failures clustering. A handful of Forbidden errors is normal churn — people block bots — but a sudden jump is a signal about the previous message, not this one. A subscriber who blocked the bot is counted as failed and left alone rather than retried in a loop; the drip system treats the same signal as terminal, recording one blocked row so the queue stops regenerating work for a dead chat.
Sends are paced with a delay between messages, because Telegram throttles bots that burst. For the mechanics — the rate ceilings, what a 429 with retry_after means, and why adding workers makes a throttle worse — see the guide to Telegram broadcast limits.
Recent broadcasts stay in a side panel with a replay action that reloads a past send's text, media, buttons and filters into the composer — the fastest way to run a proven message against a different segment.
The two send paths answer different questions. A broadcast answers "what do I want to say today?" — it fires from your calendar, reaches everyone matching a filter at once, and is the right tool for a launch, a limited offer, or a piece of news. A drip answers "what should this person hear next?" — it fires from the subscriber's own join time, so a subscriber who joins tonight gets the same day-two message tomorrow that last month's cohort got on their day two.
In practice the drip carries the evergreen onboarding argument and the broadcast carries anything with a date on it. Teams that push everything through broadcasts end up re-sending the welcome offer by hand to people who already saw it; teams that push everything through drips cannot react to a Tuesday-afternoon opportunity at all.
Because drips target the same language, source, tag and category attributes broadcasts do, it is easy to hit the same people twice in one day from two directions. The shared targeting vocabulary at least makes that overlap visible before it happens.
Team access is per bot, with owner, admin, editor and viewer roles, so a copywriter can build and preview a broadcast without holding the ability to fire it at the whole list.
mySkua is currently an invite-only private beta, so accounts are not opened on demand. Access is granted in batches to teams already running Telegram funnels — if that is you, join the waitlist and tell us roughly how large your subscriber list is and which languages it spans. Those two details are what we use to prioritise invitations.
Worth reading meanwhile: the Telegram broadcast limits guide for the constraints every mass sending tool works under, and audience segmentation for how subscribers acquire the attributes a filtered send depends on.
Want this on your own bots?
mySkua is in a closed beta and accounts are opened in small batches. Tell us what you run and we will come back to you.
Request access