Watch Botable work

Everything said in the video, in order.

A Telegram bot is two separate things that beginners tend to merge into one. There is an identity, which Telegram issues, and there is a program that answers messages, which somebody has to write and keep running.

Botable gives you both from a description. Here is the whole path, from an empty box to a bot people can message.

This is the dashboard. Every bot you own is listed underneath, with whether it is currently live, and the box in the middle is where new ones begin.

You describe the bot the way you would describe it to a colleague. There is no template to choose and no syntax to learn.

Be specific about what it should actually do. Every detail you give here is a correction you do not have to make later.

A token is Telegram's proof that the bot is yours. Create with Telegram is the short way round: Telegram creates the bot and hands the token straight to Botable, so you never visit BotFather at all.

If you already made a bot with BotFather, switch to I have a token and paste the string it sent you. Botable checks it against Telegram before it accepts it, so a typo fails here rather than an hour from now.

Press Enter and you land in the workspace for that bot. The left pane is the build itself, arriving as it happens rather than after it finishes.

You can open any step and see exactly which files were read and written. And you can close the tab: the build runs on the server, not in your browser, so it carries on without you.

There is no deploy button anywhere in this product, and that is deliberate. When a build finishes, the bot is already registered with Telegram and already answering messages.

Start opens your bot inside Telegram, which is the only real test that matters. Send it something and watch it answer.

Everything after this is another sentence in the same chat. Add a command, change the wording, connect an API. The loop never changes.

Describe it, connect a token, and let it build. Start free at botable dot I O.

Everything said in the video, in order.

Every Telegram bot needs a token, and the usual way to get one is a conversation with BotFather. Run slash newbot, invent a name, invent a username nobody has taken, and copy a long secret back out.

Botable has a second route, where Telegram creates the bot and hands the token over directly. This is what that actually does.

Start with the path most people know. This tab takes a token that already exists, and the link under the field is where you would get one.

A token is Telegram's proof that the bot is yours. It is a secret you carry by hand between two apps, and one wrong character fails on submit.

Create with Telegram removes the carrying. Telegram makes the bot and passes the token to Botable over its own API, so it never touches your clipboard.

What is left for you is the description, the one part Telegram cannot supply. The name, the username and the token all arrive with the bot.

Enter creates nothing yet. Botable opens a short-lived row, generates a random sixteen character token, and hides it inside the username it suggests to Telegram.

The link opens Telegram on its own create-bot dialog. You name the bot there and confirm. Telegram creates it, and sends that name back to Botable.

Back here the page does not poll. It holds a single open connection and waits, so nothing is spending requests while you are in the other app.

When you confirm, Telegram posts the new bot to Botable's manager bot. The username still carries that random token, so Botable knows whose row it is.

Botable asks Telegram for the token, checks it, and saves the bot with your description already in it. The open connection fires once, and that is the redirect.

That delivery also links your Telegram identity to this account. Nothing had to be connected first, and afterwards Botable has a second way to recognise you.

The waiting row lives fifteen minutes. Let it lapse and Botable says it timed out and lets you start again, rather than leaving a half-made bot here.

No BotFather, no token to carry. One description and one confirmation. Start free at botable dot I O.

Everything said in the video, in order.

Adding a bot to a group is two grants, not one. It joins like a member, and is then allowed almost nothing.

The gap between them is why a bot that looks broken in a group is usually behaving exactly as configured.

Manage's Share link row holds the only thing a group needs — the handle at the end of the link. Copy it, then in the group choose Add Members and search for it.

It joins as an ordinary member, which is already enough to answer commands. If that handle never turns up in the search, group joining is off in BotFather.

Then it ignores the conversation. Privacy mode is on by default, so out of a whole group it gets only commands aimed at it, replies to its own messages, and service messages.

Turning it off in BotFather skips groups it already sits in, so remove it and add it back. Make it an admin instead and it receives everything, not just this list.

Acting on the group is the second grant, given one right at a time. Delete messages to moderate, pin to announce, ban users to enforce, invite users for links.

Grant those and no more. A missing right fails quietly, so open Logs when a group command does nothing: a code fault turns up red here, a missing right turns up as nothing.

Join it, then grant it, and no more than it needs. Start free at botable dot I O.

Everything said in the video, in order.

BotFather has more than twenty commands. Ten decide anything day to day, and here is what each of them does.

Four of the ten you stop typing the day your bot lives here, because Botable writes those to Telegram for you.

Slash newbot begins every bot. It asks for a display name, then a username ending in bot, and answers with the token. That handle is permanent.

Four fields, four BotFather commands: slash setuserpic and slash setname up top, then slash setabouttext for the short one and slash setdescription.

Edit one and Save changes sends that field to the Bot API on its own. It reaches Telegram immediately, and nothing about your bot is redeployed.

No token appears on this screen. Slash token is how you get yours back, and slash revoke is the emergency: the old string dies the moment you run it.

Slash setprivacy is on by default: in a group your bot hears the slash commands here, and nothing else. Change it and re-add it to groups it is already in.

Slash setcommands writes the menu beside the message box; this screen only counts what people press. Delete Project is not slash deletebot — only that frees the handle.

Four of them you never type again. The rest take a minute. Start free at botable dot I O.

Everything said in the video, in order.

Telegram charges nothing for a bot. That is true, and it is the least interesting line in the bill.

What costs money sits behind it: a process that stays awake, somewhere to keep data, and the APIs it calls.

Five hundred and fifty nine messages have passed through this bot. Telegram billed none of them. No registration fee, no per-message fee, no paid tier.

The only money Telegram itself handles is Stars, and that flows toward you. Every cost you pay is on the other side, wherever the bot is running.

The last thirty days: messages arrive whenever people happen to write. Free hosting that sleeps when idle wakes late on the first one, and reads as a broken bot.

Self-hosted, that is three bills: a machine, a disk, and any paid API you call. A platform can absorb the first two. The third stays yours either way.

Free gives you one bot, running in forty-eight hour stretches you restart. Forty dollars a month keeps three awake around the clock, and unlimited bots start at forty nine.

A credit is one piece of AI work: one to build a bot, one for each change. New accounts get fifteen. Running, redeploying and logs are never metered.

Telegram free, hosting never a separate bill, credits only for AI work. Start free at botable dot I O.

Everything said in the video, in order.

A bot token is one line of text that Telegram hands you. It is not a setting on the bot — it is the bot. Whatever holds that string can act as it.

So it pays to know what the string is, why Botable checks it on entry, and what to do the day it ends up somewhere public.

I have a token is the tab for a bot that already exists, one you made in BotFather. The other tab has Telegram make the bot and hand the token over, so you never see it.

A project needs two things: what the bot should do, and the Telegram identity it runs as. The description is the easy half.

The token is the other half. Digits, a colon, then a long random tail. The digits are the bot's public Telegram ID; everything after the colon is the secret.

No password beside it, no account behind it. A token in a screenshot or a public repo is a working bot for whoever finds it — they read every message and answer in your name.

Botable does not take the string on trust. It asks Telegram whose bot this is, and once that clears the token is attached to a project like this one. The name in the corner came back with the answer.

So did the public link. Nobody typed Lumen Support or its t dot me address into Botable — one call with the token and Telegram returned the name, the username, and the link people use to find it.

That check is also why a token cannot be used twice. A token already registered is refused: one Telegram bot, one project, across the whole platform.

After that you never type it again. Botable signs everything with it — registering the bot, pulling the names in your audience, sending a broadcast.

Which is why, the day a token is revoked, every screen that talks to Telegram stops with it. This one is asking Telegram to describe a bot whose token no longer opens anything.

Not deleted, not broken — only no longer holding a key that works. And the fix is not in Botable: open BotFather, revoke the old string and ask for a new one. The old one dies the instant you do.

Paste the fresh token into the project and it is verified and registered exactly like the first. Your code, your database and the people already in your audience carry on untouched.

Treat it like a password, and rotate it the moment you doubt it. Start free at botable dot I O.

Everything said in the video, in order.

The builder is not a box that generates a bot from a description. It is an agent with file tools, working inside your bot's own directory, on code that is already running.

Which means how you write a request changes what comes back. These are the habits that get it right the first time.

This is the whole life of one bot in a single thread. The first message is the one that created it, and everything under it is a change to something that already exists.

The second request does not start the bot over. It lands on the files the first one produced, so the work you asked for earlier stays exactly where it is.

So the request can be small. You are describing a difference, not the whole product, and anything you do not mention is left alone.

Open any reply and it shows you what it actually did — every file it opened and every file it touched, in the order it happened.

It read the file that owned the FAQ before it changed a line of it, and the other two are the files that feature reaches. Reading first is what stops it overwriting something it never looked at.

Ask for one thing. A message with ten features in it gets broken into parts and built one part per reply anyway, so the list only delays the first working version.

This one is the right shape. One feature, the behaviour named, the price stated — and four steps and two files later, that is everything it changed.

The run happens on the server, not in this tab — close the browser and the agent keeps going. Nobody typed this message: the platform caught a crash in the logs and posted the fix itself.

Describe what your users will see, not how to build it. A confirmation that reads like a robot is a usable instruction; which file the wording lives in is not your problem.

And the reply comes back in the same register: what your bot now does for the people using it. The one file it touched is a click away, and out of the way until you ask.

Put the trigger and the behaviour in one sentence, in the words a user would recognise.

Then the case you already know will come up. That sentence is the whole interface, and it is the only part the builder cannot work out on its own.

One change, said as behaviour, and let it read the code first. Start free at botable dot I O.

Everything said in the video, in order.

Every bot chat has a menu button beside the message field. Tapping it opens the commands the bot advertises.

You register that list with Telegram yourself. A command nobody can see may as well not exist.

Flow draws every handler in this bot, parsed straight out of the code. It is the honest list of what Lumen Support answers to, buttons included.

Manage, then Audience, ranks those same handlers by use. The rows with a slash are the commands. Everything else is a button, and a menu can only hold commands.

Narrow it to seven days and the order barely moves: start, ticket, status, help. Telegram shows a menu exactly as you register it, so register it in that order.

Botable has no field for this, and a menu typed into BotFather goes stale. Ask in the composer instead, in that order, and say what each one does.

That description is the line people actually read, so keep it plain. Scope rides on the same call, and scope is what keeps admin commands off everyone's menu.

The agent writes the call into the code that runs on load, so every reload registers the list again. The deployment log then shows the traffic: start, status, faq.

The cheapest discovery your bot will ever get. Start free at botable dot I O.

Everything said in the video, in order.

Telegram gives you two button systems. They look alike in a screenshot and behave nothing alike in a chat.

Picking the wrong one is the most common mistake in bot design. Here is how each behaves, and when.

An inline keyboard belongs to one message. The Flow view draws each screen the way Telegram will, so the buttons sit right under the text they arrived with.

Tapping one sends a silent callback rather than a message. Nothing lands in the chat, and the bot can rewrite that same message in place instead of sending another.

A reply keyboard is the other kind. It replaces the person's typing keyboard, so a tap arrives as an ordinary text message — and nothing on this map uses one.

It also outlives the message it came with, staying until the bot removes it. That fits a fixed main menu, like the one this card drops you back on, and little else.

In a group that becomes noise. Everyone there sees the keyboard unless you mark it selective, and every tap posts a visible message into the conversation.

Every button on this map is inline, and the dot under one is where its thread leaves. Use inline unless you want the choice to appear as a message the user sent.

Two button systems, one right answer nearly every time. Start free at botable dot I O.

Everything said in the video, in order.

A bot can hand someone a photo, an invoice, a whole PDF. Telegram will take that file three different ways.

Which way you pick decides whether the send is instant or slow, and whether it works at all.

Describe the file and the moment it goes out. Botable writes the send. Everything after this is what makes that one sentence a better one.

Broadcast sends that kind of message by hand. An empty note, an attach button in the toolbar, and a limit of four thousand and ninety six characters.

Attach the price list and the message becomes a photo. Whatever you write is now its caption, and the counter drops to one thousand and twenty four.

That attach uploaded the bytes once. Telegram keeps the copy and gives your bot a file I D — pass that I D next time and nothing is uploaded again.

Bytes have ceilings: ten megabytes for a photo, fifty for anything else. A public URL Telegram fetches is five and twenty. A file I D has no cap.

As a photo, an image is compressed and shown inline. As a document it arrives byte for byte. Screenshots and price lists want the second one.

Upload once, reuse the I D, and watch the caption length. Start free at botable dot I O.

Everything said in the video, in order.

Telegram tells your bot which language each person's phone is set to, before anyone types a word.

A good default, and a bad assumption. The rest of the job is keeping your strings where you can find them.

Ask for both halves in one sentence. A default taken from what Telegram already sends you, and a plain way for someone to overrule it.

The sender's language code rides along with the message, no question asked. Lumen Support keeps it in a column of its own, next to the name and the plan.

Sixty people here and twenty four languages between them, eight on English. Nobody was asked. But that code is the phone's setting, and it can arrive empty.

Default from it, then offer a way out. A language command with buttons, stored against the user I D. Telegram lets you set the command menu per language too.

Keep the words out of the handlers. This greeting sits in a keyed table. Strings buried in the logic are why error messages stay English after everything else ships.

Machine translation is fine for chat replies and help text. Billing is the other kind. A wrong refund line is a dispute, not a typo, so have a person read those.

Default it, let them change it, keep the strings together. Start free at botable dot I O.

Everything said in the video, in order.

A message to the agent normally ends the same way. Files written, the bot reloaded, and a new entry in its version history. Most of the time that is what you want.

Plan mode is for the times it is not. The agent reads the bot, writes nothing, and tells you what it intends to do before any of it happens.

Every change to this bot began as a sentence in this chat. The agent reads the code, edits the files, and the running bot picks the changes up when the run finishes.

It also leaves a trail. The clock in the header opens the version history: one entry for every run that changed code, so an earlier one is always there to go back to.

Plan mode decides what a message does before any of that happens. The control is the clipboard button beside the send arrow.

Switch it on and it stays on until you switch it off, so it holds for a stretch of careful work rather than a single message.

Then write the request the way you would have written it anyway. The sentence does not change, only what the agent may do with it.

A run that wrote code says so on the chip: four tools used, two files changed. A plan can list what it read, and never has that second half.

The run that follows gets three tools: read a file, search inside them, list them. Writing is not in the set, so a plan cannot quietly become the change.

What comes back is a brief in plain language. What it will do, what it will add or change, what you should know — the risks, any outside key it needs — and how big it is.

Nothing was written, so nothing follows. No new version appears behind that clock, nothing is deployed, and a plan you disagree with costs you a reply rather than a rollback.

If it reads right, Approve and Execute sits underneath it. The same work runs again with plan mode off, and the agent builds from the plan you just read.

Two things earn the extra step. A change large enough that you want to see its shape first, and a bot you inherited rather than built.

For small edits, turn it back off. A plan is a full agent run and costs credits like any other message.

See the plan, then approve it. Start free at botable dot I O.

Everything said in the video, in order.

Most analytics tools make you learn the tool before you can ask the question. Pick a metric, pick a window, build a chart, then find the question was wrong.

Ask your data goes the other way round. You type the question into the same chat you build the bot in, and the answer comes back drawn.

The bar chart button in the composer, immediately left of the one for images, is a mode switch rather than an action. Hovering it says what it does.

Switch it on and the next message you send goes somewhere else entirely, to a read only analyst that knows this one bot.

Read only, as the tooltip says, is the toolset. No Write, no Edit and no Bash is handed to this agent, so a question never leaves the bot different.

What it reads instead is data. Every bot keeps its own SQLite database, the one this tab browses, and the analyst queries that same file.

These are your bot's own tables, written by the bot as it runs. Tickets, users, whatever it keeps, and nothing at all from anybody else's bot.

That connection is opened read only at the operating system level, with query only set on top of it. A write is not declined here. It fails.

A validator runs before any query lands. Anything that does not begin with SELECT or WITH is rejected, and so is any word that writes.

The other source is usage. Every message that arrives is written down as an event, and this chart is those same events counted by day.

You ask the way you would ask a colleague. There is no metric to choose, no window to configure, and no chart type to pick.

A question like this one is three configuration screens in an analytics tool. Here it is a sentence, typed into the box you build the bot in.

Enter sends it, and the answer lands in this thread as a sentence with its chart underneath. It is the one message in Botable that changes nothing.

The answer to that question is also sitting right here. Manage ranks every command and button by how often people pressed it, for when you would rather look than ask.

A read only analyst that cannot touch the bot, and answers in charts. Start free at botable dot I O.

Everything said in the video, in order.

A bot that is running produces facts about itself — who opened it, what they pressed, who came back a week later. Manage is where they live.

It is one screen with a rail of eight rows. Five behave one way, three behave another, and that difference is the whole layout.

A project opens on Manage. The rail on the left holds eight rows, and the pane beside it always belongs to whichever row is lit.

The line under each label is not a caption. It is that section's live reading — people active today, messages in the window, audience size.

The first five rows are all the same page. Picking one scrolls its card into view rather than loading anything — nothing is hidden, only further down.

Growth and retention carry their definition underneath the figures, because a retention number means nothing until you know which people it counted.

The fifth row is the share link and its QR code. Every share you hand out lands in the chart above within a minute.

The last three rows do not scroll. They replace the pane, because what they hold is not a bigger version of a number, it is a tool of its own.

Audience is every person who has messaged the bot, with the commands and buttons they used ranked above the list. Open a row for one person's history.

Broadcast writes one message to all of them and renders it as the Telegram bubble it will arrive as, so you see it before anyone gets it.

Payments is the Stars side of the same bot: the plans you sell, who is subscribed, and what has come in. Changes here apply on the bot's next reload.

On this bot all three are open. While one is still building, asleep, or its token has stopped working, they sit greyed out — there is nobody to list or send to.

The header names the row you are on and stamps the time that reading was taken. It re-reads itself every fifteen seconds while the tab is open.

Refresh forces it early, and the glyph beside it opens the bot in Telegram — which is where you check whether any of this is true.

Eight rows, one screen, and every figure read from the live bot. Start free at botable dot I O.

Everything said in the video, in order.

Every message someone sends your bot is recorded automatically. The Manage tab is what that record adds up to.

Each card answers a different question, and knowing which question is the whole skill. A number you misread is worse than none at all.

Nothing here needed installing. Each update is written down as it arrives, before your bot's own code sees it, so the numbers start with your first user.

Every row on the left carries its own reading, so the rail is already a summary. Only what people send is counted: replies your bot writes are not in these figures.

Right now is the headline. How many people were active today, this week, and this month: three counts of the same audience over widening windows.

Each person counts by their most recent message, so today means the last twenty-four hours, not since midnight. Today rising while this month sits flat is the same people, more often.

Activity plots two lines against the same days. One counts messages, the other counts how many separate people sent them that day.

Rising together means more people arriving. A messages line that climbs while the people line stays flat means a smaller group talking more.

The filter above the chart changes the span. Seven days redraws both lines against the last week, and the message count beside the legend follows.

Twenty-four hours changes the shape, not just the scale. Buckets become hourly, which is how you find the times of day people use it.

That filter moves this chart and nothing else. Active users, growth and retention come from fixed windows and ignore whatever you pick here.

New is a first ever message in the last seven days, returning is anyone active on two different days, churned is silent for thirty days or more. They overlap and never sum to your total.

Retention is the cohort question. Of the people who joined at least a day, a week or a month ago, the share who came back on a later day inside that stretch.

Day thirty reads zero on a young bot, and that is not a verdict. Nobody has been here thirty days yet, so nobody could have come back. It fills in as the bot ages.

The record is already being kept. Reading it correctly is the only part left to you. Start free at botable dot I O.

Everything said in the video, in order.

A dashboard tells you how many people used your bot. It almost never tells you who they were, or what any one of them touched. The Audience pane is the half of the picture that names names.

None of it is something you switch on. Your bot already handles every message and every button tap, and Botable writes down what happened while it does.

Audience sits in the rail beside the charts, carrying a running count of everyone who has ever messaged this bot.

Total users is that same everyone. Returning and Premium are cuts of the same set, not separate groups, and the row of windows above scopes all three.

Returning has an exact definition instead of a vague one, and the panel will tell you what it is: somebody who came back after a gap of three days or more.

Underneath, the ten commands and buttons your bot handled most, ranked by count, each with its share of every interaction in the window.

A grey tile is a command. A blue one is an inline button, showing the caption a person saw, with the callback value your code receives printed underneath.

You never declared these names. The runner reads each update as it arrives and notes the command, the callback data, and the caption of the button behind it.

The list below is the audience itself, most recent activity first. Every row is one person: their handle, their message count, and when you last heard from them.

New marks a first message inside the last seven days. The star marks a Telegram Premium account. Both come off the update itself, and stay current on their own.

Open somebody and you get their whole history with this bot: how many messages they have sent, when they joined, when you last saw them.

Below that is the replay. Every command, every button tap, every photo they sent, newest at the top.

It keeps the last sixty interactions for that person, which is usually enough to see why somebody stopped, or which button they never found.

Your users are a list of people, not a number, and every line on it is something your bot already saw. Start free at botable dot I O.

Everything said in the video, in order.

A bot's audience is a list of real people who chose to message it. Botable will hand you that list as a spreadsheet, and it is worth being exact about what is on it.

Where the control is, the two formats it writes, the columns you get, and the one thing the file cannot do for you.

The Audience pane opens on everyone who has ever messaged this bot. The row of windows at the top narrows that, and every card below it follows.

Seven days here is thirty-eight people rather than fifty-two. The file takes whichever set is on screen, and the list holds the thousand most recent.

Back to everyone. Export sits in the header of the Users card, and it is the only control in Botable that writes your people out to a file.

There is no export job and nothing arrives by email. The file is built in your browser out of the list already loaded, so it saves the moment you choose.

Comma separated values is the plain one. It opens in Sheets, Numbers and anything that reads a table, and it carries the marker Excel needs to keep accented names intact.

The Excel option writes a workbook, where the message count arrives typed as a number rather than text. Same rows, same order, the same six columns.

Those columns are what a person's own card already shows: name, username, how many messages they sent, when they joined, and when you last heard from them.

In the file both dates are full UTC timestamps, and a sixth column the screen never shows comes with them: the Telegram numeric ID, which never changes.

What is absent matters more. There is no email address and no phone number, because an ordinary Telegram message does not carry either one.

A username is a handle inside one app. People change theirs and some never set one, which is why the numeric ID is what you key your own records on.

Everyone on this list opened a chat with your bot, and that chat is the only channel you have to them. Broadcast is how you use it, one row down.

Take the file for your own numbers, and reach people where they opted in. Start free at botable dot I O.

Everything said in the video, in order.

A bot that answers perfectly in a private chat can look dead in a group. Commands work. Nothing else does.

That is privacy mode — a Telegram setting, on by default, deciding how much of a group your bot is handed.

Every trigger the bot has is a card on this map. In a group with privacy on, the ones that start with a slash are most of what reaches it.

Button taps get through too. They are callback queries, not messages, so privacy never touches them — an inline keyboard works the same in a group.

This card is the catch-all that answers any plain message. In a group it never runs, because the message is never delivered to your bot at all.

The handler is not broken. It answers every private chat exactly as written. Privacy mode is a group rule, which is why the two behave differently.

That part happens in Telegram, not here. Send slash set privacy to BotFather, pick your bot, choose Disable — or add the bot to the group as an admin.

Disabling privacy applies when the bot joins. Groups it is already in keep the old behaviour until you remove the bot and add it back — then everything on this map can fire.

Leave it on unless your bot genuinely needs to read the room. Start free at botable dot I O.

Everything said in the video, in order.

Your bot has to learn that a message arrived. Telegram offers exactly two ways, and they cannot both be on.

Long polling has the bot ask. A webhook has Telegram tell it. Botable does only the second, on purpose.

A webhook is one HTTPS address you register once. Telegram posts each update to it the moment it happens, and this line is that registration.

Long polling is the reverse: the bot calls getUpdates in a loop and waits. This bot never does — it registered instead, and reports zero pending.

Every update line below it is one delivery Telegram pushed. Nothing runs in between, so an idle bot costs nothing and a busy one is never a poll interval late.

You cannot have both. While that registration stands, Telegram refuses getUpdates, so a webhook left over from a test is why a polling bot goes quiet.

Polling still wins in one place: your laptop. It has no public address for Telegram to post to, so a webhook there needs a tunnel that moves every restart.

Deploying here registers that address for you, one per bot. Redeploy swaps the code behind it and the log comes back to the very same hook.

No poll loop, no tunnel, one address per bot. Start free at botable dot I O.

Everything said in the video, in order.

A bot you add to a group can read and reply. Deleting a message, muting or banning needs more than that.

Admin is not one switch. It is a list of separate rights, and you want to grant the fewest that work.

Botable writes the handler. Telegram decides whether it may run. You promote the bot from group info, and only after it has joined as a member.

Ask for moderation the way you ask for anything else. The permission is the half you cannot ask for here — it is a toggle on Telegram's side.

That one sentence needs two rights: deleting messages, and restricting members. Missing either, the handler runs, Telegram refuses, and the group sees nothing.

Muting and banning are the same right, not two. Deleting other people's messages is its own. Pinning an announcement is its own again.

Turn on what those two features need and stop there. Every extra right is one more thing the bot can do to your group the day its token leaks.

Promotion has a side effect. An admin bot always receives every message in the group, whatever privacy mode says, so leave a command-only bot unpromoted.

Grant the one right the feature needs, and nothing more. Start free at botable dot I O.

Everything said in the video, in order.

A bot can publish to a Telegram channel. What it cannot do is sit in one as an ordinary member.

It is an administrator there or it is nothing, and one specific right decides whether it may post.

Telegram grants that, not Botable. In the channel's administrators list, add your bot and turn on Post Messages. Add Edit Messages if it will update posts.

Miss that one right and the failure is quiet — your handler runs, Telegram refuses, and the channel shows nothing. Ask Botable for the posting itself.

The send is ordinary. The same call your bot makes to a person, aimed at a channel instead. A public channel has a handle of its own, like the bot's here.

A private channel has no username, so you need its numeric id. It is negative, it begins with minus one hundred, and your bot can read it off a forwarded post.

The Broadcast screen is the closest thing on this page, and it is a different job. It reaches the fifty three people who have written to this bot.

Everyone here means everyone who messaged the bot. A channel post is your own code sending to a chat id, on your own schedule, with this page closed.

Admin rights, the right chat id, and the code does the rest. Start free at botable dot I O.

Everything said in the video, in order.

Sooner or later your bot needs a number. Message this person. Post in that group. Treat this account as the owner.

Telegram identifies every chat by a numeric id. The name and the username sit on top of it, and both can change.

Manage, then Audience, lists everyone who has messaged this bot. Each row carries a display name and a username. Neither one is an identifier.

A username belongs to whoever holds it today. Change one and every record keyed on it goes missing. Someone else claims it and inherits that history.

The bot keeps the number itself. In the Database tab, Lumen's users table has telegram id as its primary key. The username is an ordinary column beside it.

Search the users table for that username and the number is right there. A user id never changes; a group's does, the moment it becomes a supergroup.

Clear it, and every id here is positive, because every row is a person. Groups come back negative, and supergroups and channels begin minus one hundred.

Nothing turns someone's username into their id. A bot learns the number when that person messages it, so add a command that reads both back.

Keep the number, show the name, key nothing on a username. Start free at botable dot I O.

Everything said in the video, in order.

Telegram caps how fast your bot can send. Cross a cap and the send is refused, not the bot.

The numbers are published, the penalty is a wait, and Botable already paces broadcasts under them.

Telegram publishes three numbers: about one message a second into one chat, thirty a second across all chats, twenty a minute into a group. This audience is fifty three chats.

Those are approximations, not hard edges. Telegram tolerates short bursts, and for a list far bigger than this one it suggests spreading the send over eight to twelve hours.

Cross a ceiling and Telegram answers 429 with a retry after value. It lands in Logs with every other answer it gives, and Botable waits that value out before resending the one that failed.

Botable's job is never to get there. Open Broadcast and the send button carries the count, because a message to fifty three people is fifty three separate API calls.

It asks once more before it goes. Behind the button there is no tight loop — Botable leaves fifty milliseconds between sends, about twenty a second, under Telegram's thirty.

So treat a broadcast as a job, not an instant. Back out, tick Schedule for later, and the server runs it on time whether this tab is open or not.

Send under the limit, and honour the wait when you hit it. Start free at botable dot I O.

Everything said in the video, in order.

Telegram's Bot API has no scheduler. A bot sends when told, and nothing holds a message until later.

So the clock runs on your side, in one of two places, depending on whether the send happens once or repeats.

A scheduled broadcast waits on Botable's server, not inside Telegram. This pane is where a send gets a time instead of going out now.

Schedule for later swaps the send for a moment you choose. The field reads your browser's clock, and it refuses anything already in the past.

Pick a time, and the button offers to schedule rather than send. Confirming hands the message to Botable's server, which is what waits, not your browser.

Anything queued shows here with its time and a cancel. The server sweeps for due sends every thirty seconds, claiming each one so it never goes twice.

A broadcast is one message at one moment. Every weekday at nine repeats, and repeating belongs inside the bot, so you ask for it in the chat.

Send that and the schedule ends up inside the bot's own code, on node-cron, which the runtime already ships. Name the timezone, or it follows the server's clock.

One-offs wait in the queue, repeats live in the bot. Start free at botable dot I O.

Everything said in the video, in order.

A bot token is a bearer credential with no scope. Whoever holds that string is your bot.

Almost every incident is the same short list: where the token lives, who is asking, and how fast you rotate.

This panel is Botable calling Telegram with your token. The string is not on this screen, and not in your bot's code — your handlers get a bot already signed in.

Everything on this panel is what users see. The token is what lets it be rewritten — so whoever holds the string answers in your name, and can repoint the webhook.

Rotate first, investigate after. Revoking in BotFather retires the old string instantly; the project takes the new one and the people already here carry on.

The most common hole is an admin command that checks nothing. Your bot cannot tell an admin from anyone else, so name who counts when you ask for it.

Check the id on the update, not the one you assumed. Usernames change hands, and an inline button can be pressed by anyone who can see the message.

Everything a user types is untrusted. Pass it to the database as a bound value, never as part of the query, and keep only the fields the bot needs.

Rotate fast, check the id, trust no message. Start free at botable dot I O.

Everything said in the video, in order.

Nobody mutes a bot over one weak sentence. They mute it after the third message that was not meant for them.

So most of a broadcast is decided before you write it: who gets this one, and why they would open it.

Everyone is all fifty-three people who ever messaged this bot, still listening or not. Active seven days cuts it to the forty-one still around.

That number is a live query, not an estimate. Add the thirty-day window and it re-counts to fifty-three, the whole list. Drop it, back to forty-one.

Write to one person, not a list. The name token drops a placeholder each copy fills with that reader's own first name. Where Telegram has none, it reads there.

Then the reason, in the first line. One thing that changed and what it means for them. A greeting carrying no news is what teaches people to swipe past you.

Send a test first. It goes out through the real bot as a real message, so a dead link or a broken tag lands on your phone instead of on forty-one others.

The send asks once, naming the exact number and saying plainly it cannot be unsent. Forty-one people who have not muted you yet is what you spend here.

A smaller list, one real reason, a test on yourself first. Start free at botable dot I O.

Everything said in the video, in order.

Retention is three percentages on one card, and each one is easy to read as a grade when it is not.

They are cohort numbers with a shifting denominator. Who is counted in each one decides what it can tell you.

The clock starts at each person's own first message, not on a shared date. Day thirty counts only people whose first message is at least thirty days old.

Everyone newer is left out of that figure rather than counted against it. A young bot reads zero at day thirty because the denominator is empty.

There is no cutoff at the other end. Every person old enough is in the average, back to your first user, so a genuine improvement moves it slowly.

Coming back means writing on a later day than the first. A long opening conversation counts once. Button taps count, and replies your bot sends never do.

Day seven already contains everyone from day one, so this is not a decay curve. Day thirty sitting lower is a different, older group answering, not a drop.

The lever is a reason to open the chat on a different day. A broadcast or a scheduled message only lands here when it makes someone write back.

Read the denominator before you judge the percentage. Start free at botable dot I O.

Everything said in the video, in order.

Stars are bought inside Telegram, so paying is two taps and no card form. The awkward part is the unit.

Nobody has an instinct for what a Star is worth, so the price gets guessed. Three things make it not a guess.

Revenue and M R R each carry a dollar estimate underneath, taken at Telegram's creator payout of about one point three cents a Star.

The price field is bare Stars, so you convert. Two hundred and fifty a month is a little over three dollars. Decide in dollars first.

Do not price the feature list. Price the job the tier does. A one hour first response is worth what an hour of waiting costs that person.

Trial days sit on the plan. Your bot offers a try seven days free button, nothing is charged, and each person gets exactly one trial.

A coupon is a heavier lever. On a subscription the discounted price becomes the renewal price, so thirty percent off repeats every thirty days.

M R R counts what still renewing subscribers actually paid, off the payment ledger. It moves when a renewal lands, not when you change a price.

Price the job, not the feature list. Trial, not discount. Start free at botable dot I O.

Everything said in the video, in order.

Your bot has stopped answering. Five minutes of checks, in the order that finds the cause fastest.

Connection before code. A bot that never received the message cannot have written an error about it.

Sleep is the cheapest check. After seven days with no incoming message a free bot is disconnected from Telegram, and this button becomes Turn on.

Then the token. Telegram Settings reads this bot's profile from Telegram using it. If that loads, the token is good. If it does not, only a fresh one helps.

Now the log. That red number is distinct problems parsed out of the log, not a count of red lines, and it disappears once you are on the tab.

This is the bot's own output, streamed as it runs. The red line is the failure, and it names the file and the line number that threw.

Everything here was written after the most recent reload — the runner wipes the panel as the bot restarts. So a crash you already fixed cannot be what you are reading.

Code that fails to load repairs itself: the runner reports it, and a fix lands in the chat labelled Auto-fix, costing no credit. Anything subtler, ask there.

Check the connection, read the log, let the fix run. Start free at botable dot I O.

Everything said in the video, in order.

A broadcast is one message sent to everybody who has ever written to your bot. It is the loudest thing this product does, and the screen is built accordingly.

Botable draws it as the Telegram bubble it will become, and gives you a way to send it to yourself before it goes to anyone else.

Broadcast sits low in the Manage rail, under the audience it will go to. Its line says whether anything is queued or already on its way.

This is not a form with a preview beside it — the chat window is the form. Same wallpaper, same avatar, same bubble your reader gets in Telegram.

Every keystroke redraws the bubble. The token in the toolbar drops a placeholder wherever the cursor is.

When it sends, every copy carries that person's own first name. Telegram does not always supply one, and where it is missing Botable writes there.

Telegram accepts a short list of tags and refuses the rest. The toolbar produces exactly that list — bold, italic, underline, strikethrough and links.

Anything the browser adds on its own is stripped before the message leaves. One unknown tag and Telegram refuses the whole send.

A broadcast can carry tappable links. Each takes a caption and a URL, and appears under the bubble the moment both are filled.

Six is the limit, and each sits on its own row. A bare domain is fine — the https goes on the front before Telegram sees it.

The counter is Telegram's ceiling, not ours — four thousand and ninety six characters. Attach an image and it drops to one thousand and twenty four, because the text becomes a caption.

Underneath is the one control worth using every time. Send a test to yourself puts the finished message in your own Telegram first.

Give it your username or your numeric ID and it sends the real thing — same formatting, same buttons. You have to have messaged the bot once, because a bot cannot open a chat with you.

The send button carries the number it will reach and asks once more before it goes, because there is no unsending a broadcast.

Write it, look at the bubble, send it to yourself, then send it to everyone. Start free at botable dot I O.

Everything said in the video, in order.

A broadcast is the one thing here you cannot take back. It leaves your bot, lands on a real phone, and there is no delete. Which is why this pane is mostly about who gets it.

Segments, a live headcount, a silent option and a scheduled time. All of it exists so a send can be smaller and better aimed than everyone, right now.

Broadcast sits in the Manage rail under Audience, and the line beneath it says what is queued — here, one send waiting for its time.

Write the message and the bubble above fills in as you type. That is the Telegram message itself, not a form that makes one.

Underneath is the audience. Everyone means every person who ever messaged this bot, and the number beside it is how many that is.

The pills are cuts of that same list. Active seven days is anyone whose last message landed inside the past week, and the count drops to match.

Pick a second and you get the union, not the overlap. Active seven days plus Premium is everybody in either group, so the number goes up.

New this week, Returning and Inactive thirty plus days work the same way. Everyone is the exception: it clears the rest, since it already contains them.

That figure is not an estimate. Each time you touch a pill the server re-runs the segment against the activity log and counts what comes back.

Send silently delivers with the notification switched off. It arrives like any other message, but nobody's phone makes a sound for it.

Schedule for later swaps the send for a date and time. It will not take a moment in the past, and the button changes to say what it now does.

Anything queued sits here with its time and a way to cancel it. The server checks for due sends every thirty seconds, whether or not you are watching.

Turn scheduling back off and the button is an immediate send again. Pressing it does not send anything. It asks first.

The card names the exact number of people and says plainly that this cannot be unsent. Nothing has left yet — that takes a second press.

Pick who it is for, decide when it goes, and read the number twice. Start free at botable dot I O.

Everything said in the video, in order.

Telegram will not let a bot take a card. The only rail it allows for digital goods is Stars — its own currency, topped up once and spent anywhere in the app.

That removes the two hardest parts of charging money. No merchant account, no checkout page. Only a decision about what you sell.

Payments is the last row of the Manage rail. It is the Stars side of the same bot: what you sell, who bought it, and what has come in.

Revenue is every Star this bot has ever taken. Monthly recurring revenue comes off the payment ledger — what still-renewing subscribers actually pay.

Subscribers and paying users answer different questions: people on a live subscription or trial, against everyone who ever paid, one-off buyers included.

A plan is four fields. A price in Stars, whether it repeats monthly or is bought once, how many trial days it opens with, and an identifier your code uses.

Zero Stars is a real plan, not the absence of one. The plan marked default is what somebody is on before they have paid you anything.

The features box is not marketing copy. Each entry is a key, and your bot code asks plans dot can whether the person in front of it holds it.

A new tier starts as a card at one hundred Stars a month. You name it, price it, and list what it unlocks.

Configuration alone earns nothing. Nothing in the bot yet knows this tier exists, or which command it should stand in front of.

Which is why the button reads Save and wire up. It writes the plans to the bot, then hands the list to your A I builder, which asks where each one applies.

A coupon is a code and one of three effects: a percentage off, a flat number of Stars off, or extra trial days, applied as somebody subscribes.

Below that is every customer who has paid, ordered by lifetime Stars, with the plan they are on and whether it is still renewing.

Filter to the ones still renewing, or to those who paid once and are done. Export takes whatever you are looking at out as a spreadsheet.

No card form, no merchant account. A plan, a price in Stars, and a builder that wires it in. Start free at botable dot I O.

Everything said in the video, in order.

A bot that remembers anything has to put it somewhere. Tickets, preferences, who signed up, what they asked for last week — all of it lands in storage the moment the bot starts running.

On Botable that storage is one SQLite file per bot, and the Database tab is a window straight onto it.

The Database tab opens the file the bot is actually using. One SQLite file, in that bot's own directory, holding everything it has ever stored.

There is no database server to provision and no connection string to keep secret. Nothing in here is shared with any other bot you own.

The list on the left is not a schema Botable imposes on you. These are the tables your bot's own code created, each with the number of rows in it.

Lumen Support keeps four. The tickets people open, the users who opened them, the FAQ topics they read, and its own settings. One click switches between them.

The strip above the column headers is the schema. Every column with its type abbreviated to a few letters, so a table this wide still fits on one line, and the primary key in bold.

Search does not ask which column you mean. It matches your term against every text column in the table at once.

Enter runs it. Eighteen tickets narrow to the one whose subject mentions a refund, and the count beside the table name drops to one.

Rows arrive fifty at a time, whatever the table. Users holds sixty, so it comes back as two pages, with the arrows at the bottom right to move between them.

This is not a read only viewer. Hover any row and two controls appear at its right edge: one opens the row for editing, one deletes it.

A wrong value is usually a one field problem. Editing opens the row as a form, one field per column. Asking the agent to fix it instead would cost a full build and a new version of the bot.

The bot is reading this same file while you sit here looking at it, so a value you save is the value the next message sees. Delete asks first, and means it: the row leaves the file.

Every bot's own SQLite file, browsable and repairable from the workspace. Start free at botable dot I O.

Everything said in the video, in order.

A bot's shape lives in its handlers, which is the one place you cannot see it. Which command leads where, which button opens which screen — that map ends up in your head, and drifts.

The Flow tab draws it for you. Not a diagram you keep up to date, but a map read straight out of the code the bot is running.

Flow sits beside Manage in every project. It opens on the whole bot at once — every screen it can put in front of somebody, top to bottom.

The card ringed in green is slash start, where a stranger comes in. Everything else is something the bot can say after that.

None of this was drawn by hand. The tab parses your bot's JavaScript and builds the graph out of it, so there is no second copy to go stale.

It parses rather than scans for text, so keyboards kept in a variable, menus built by a shared helper and handlers split across files still show up.

Full flow is everything at once, which on a busy bot is a lot of thread. Main flow starts at slash start and follows the buttons outward, once each.

Loops back to the menu are cut, and so is anything no button reaches: typed commands, catch-all replies. Twenty-two screens become fifteen.

Closer in, each card is one handler. The heading names the trigger — the command that opens it, or the button somebody tapped — and under it is the reply.

It is drawn the way Telegram will draw it, keyboard and all, so you read the screen your users get rather than a box with a name in it.

A button that leads somewhere carries a small dot on its lower edge, and that dot is where its thread leaves. The link is the button, not the card.

Botable finds them by matching each button's callback data against every handler in the bot, patterns included, not only exact strings.

Which makes an absence loud. A button with no dot answers to nothing — a link out of Telegram, or a handler you never wrote. Here every button has one.

The tab changes nothing itself. You ask for the fix in the same chat you built the bot in, and the map redraws from whatever the code became.

A map of every answer your bot has, read out of the bot itself. Start free at botable dot I O.

Everything said in the video, in order.

Every change you ask for lands on the code that is already answering real people. That is fine right up until a change makes something worse.

So Botable snapshots the bot after every change, and gives you two ways out of a bad one: put it back, or branch a copy off and leave the live one alone.

The clock in the project header swaps the chat for version history. It stays in the same pane, so reading what changed never leaves the bot.

Every line is one change that landed, newest first, grouped by the day it happened. This bot has seven, going back to the day it was created.

A version is written after each modification, and only when files actually changed. Asking the agent a question, or reading your data, does not add one.

The icon on the left says what kind of change it was. A plus is the original creation, at the bottom, and a pencil is a change you asked for.

A wrench is different. That is a fix Botable made on its own after the bot hit an error while it was running.

The tinted row at the top is the version serving people right now. It is the only entry with no restore button, because there is nothing to go back to.

Restore writes the files from an older version back over the live bot and hot reloads it. Nothing is rebuilt and nothing is redeployed.

The restore is itself recorded as a new entry at the top, so the state you left is still in the list underneath. Going back throws nothing away.

The other button copies a version into a brand new bot instead. The files come from the entry you picked, and the bot in front of you is untouched.

The copy needs its own Telegram token, because it is a separate bot with its own identity and its own audience. Nothing you do to it reaches the original.

That is the safe way to try something drastic. Fork from a version you trust, then break the copy while the live bot carries on serving people.

A snapshot after every change, a way back from any of them, and a fork whenever you want to try something else. Start free at botable dot I O.

Everything said in the video, in order.

A deployed bot is a program running on a machine you will never see. The only honest account of what it is doing is what it writes down while it runs.

That is the Logs tab. It is also where the platform notices a bot has broken, and starts repairing it before you have read a word.

The workspace opens on Manage, and a red number appears on the Logs tab by itself. You are told something is wrong rather than having to go looking.

That number is distinct problems parsed out of the log, not a count of red lines. It disappears once you are on the tab and looking at them.

This is your bot's own output as it runs — every update it handled, every payment it recorded. The figure beside the title is how many lines are being held.

The connection is opened once and kept open, so lines land as the bot writes them. There is no refresh control because there is nothing to refresh.

Colour comes from what the line says. Errors, failures and exceptions go red, warnings amber, starting and running green.

Detection reads only the lines written since the last reload, so a problem you already fixed cannot climb back onto the badge.

Redeploy restarts the bot from the files it has right now. Nothing is rebuilt and nothing is regenerated — the code on disk is the source of truth.

Press it and the panel empties, because the runner wipes that bot's log database as it reloads. What fills it again is only this version starting up.

When a bot's code fails to load, the runner reports it to the platform and a repair starts unprompted. It lands in the chat, labelled Auto-fix.

The agent is given the error, the stack trace and the last fifty lines of log, and told to make the smallest change that fixes it, then read the logs to confirm.

Botable started that run, not you, so it costs no credit. It is kept as its own version, which means you can roll it back like anything else.

You can also ask in the chat. The agent reads the same logs and error records you are reading, so the answer comes from evidence.

Watch the stream, trust the colours, let the platform take the crashes. Start free at botable dot I O.

Everything said in the video, in order.

Your bot has two names. The one in Botable is a project label, and only you ever see it. The one Telegram holds is what sits above every chat the bot is in.

Telegram Settings is where the second one lives, next to two descriptions and a photo. Four fields, each of which shows up somewhere different.

Open the bot's name in the project header. Rename, at the top, changes the label on your dashboard and nothing else. Telegram never sees it.

Telegram Settings is the other one. It opens by reading the name, descriptions and photo back from Telegram, so you are looking at Telegram's copy, not ours.

Four things can be changed here. The handle under the title is not one of them: the Bot API has no method for renaming a username.

Name is the line at the top of the chat, and what Telegram uses anywhere it lists your bot. Sixty-four characters, counted for you beside the label.

It is a display name, not a handle, so spaces and punctuation are fine and two bots may share one. Change it and every chat the bot is in shows the new name.

The short description is the one-liner on the bot's profile card and in Telegram's own lists of bots. A hundred and twenty characters, so write the sentence, not the pitch.

The description under it is the one people underestimate. Telegram prints it on the empty chat screen, before anybody has pressed Start.

So it is the only thing your bot says to someone who has never used it. Five hundred and twelve characters: what it does, and what to send first.

The photo takes JPEG, PNG or WebP up to ten megabytes. It is the one field that does not wait for Save; the upload reaches Telegram the moment you choose a file.

Save changes sends only the fields you touched. Each is its own call to Telegram, and each can fail alone, so you get a result per field rather than one verdict.

The button was grey until a field differed from Telegram's copy. None of this redeploys the bot: the identity lives on Telegram's side, not in your code.

A name, two descriptions and a photo — the whole public face of a bot. Start free at botable dot I O.

Everything said in the video, in order.

Most of what a bot does fits into a message with a row of buttons under it. A few things never will: twenty products with photos, a calendar, a cart, a form with ten fields.

Telegram's answer is a Mini App, a real web page that opens inside Telegram already knowing who is looking at it. Here is when a bot needs one, and how you ask.

Every screen this support bot has is a message with buttons underneath it. The Flow tab draws all of them at once.

Zoom in and the pattern repeats. One message, a few taps, and every branch is another message. That is the right shape for a menu and the wrong shape for a catalogue.

A mini app is a web page Telegram opens inside itself — one more screen in this map, except the screen is a page. Botable hosts it, so there is no server to rent and no domain to point anywhere.

It is not a separate product bolted on the side. The app reads and writes the same database the bot already uses, through handlers that live in the bot's own code.

And it knows who is asking without being told. Telegram signs the user's identity and the platform verifies it before your handler runs, so a copied link cannot read somebody else's rows.

A mini app never replaces the bot. Everything already in the chat goes on working, and every message on this dashboard came from somebody who only ever typed at it.

You ask for a screen the same way you ask for anything else. Same chat, same plain sentence.

Detail pays more here than almost anywhere else. A screen has a layout, a loading state and an empty state, and everything you name is something nobody has to guess.

A Mini App tab appears here, between Flow and Database, but only once the bot actually has a page of its own. This one has none yet, so nothing sits there.

Send that sentence and the page gets written into the bot's own files, beside the handlers it talks to, and the tab turns up here by itself.

Ask for a screen when a message cannot carry it. Start free at botable dot I O.

Everything said in the video, in order.

A bot that only talks to Telegram is a small bot. The useful ones read a weather service, look up an order, or call a language model — and each of those needs a key that must not end up in the code.

Botable handles that inside the same chat you build in. Here is where a key goes, who gets to see it, and what a bot is allowed to install.

This is Lumen Support. It was built entirely in this thread, and connecting it to something outside Telegram is not a different kind of task — it is the next message.

You describe the outcome rather than the plumbing. No endpoint, no auth scheme, no library name. What should happen when someone sends an order number.

One earlier build in this thread already needed a credential. This is where most tools send you off to edit a file. Botable does not — it asks you here, and prints every step it took.

It names the exact variable it needs and where the key is issued, takes it in the message you are already reading, and carries on. No settings screen, no file to open.

What you type is written straight into the bot's own environment file on the server. The code refers to it by name, so the key is never a literal in a source file.

One line comes back to the agent — saved, use it by name — and the copy that carried it is deleted. The step reads Secret added, with the key name and nothing else.

The step above it is the check. It reads what is already in the environment first, so a key you handed over on an earlier build gets reused rather than asked for twice.

Most integrations need no new package at all. Every bot is handed an HTTP client, a scheduler, date helpers, and the database you are looking at, before a line of its own code runs.

When one genuinely is missing — HTML parsing, spreadsheets, image work, the OpenAI client — it is written into a package file and the runner installs it on the next reload. You never run a package manager.

A wrong or expired key does not fail while you build. It fails while the bot runs, and Logs is where that lands — live output with the errors in red, in the order they happened.

Ask for the integration, hand over the key once, and it stays out of the code. Start free at botable dot I O.

Everything said in the video, in order.

Post your bot link in five places, and Telegram tells you nothing about which of the five actually worked.

A start parameter fixes that. The code you attach travels in with the person's very first message.

Share link in Manage holds the plain address of your bot. Copy that, post it in five places, and all five arrivals look identical.

So do not post the plain one. Add a question mark, start equals, and a short code on the end — up to sixty four letters, digits, underscores or hyphens.

Audience ranks every command and button from live traffic. Slash start sits at the top with a hundred and thirteen — a third of every interaction.

Open a person and their replay ends on slash start: the first message they ever sent. That is the one your code rides in on.

The ranking counts every start as one, whatever code followed. But each person already has a row in your database — the code needs a column beside it.

So ask the builder to save it. One column on the users table, one count per code, and the five places you posted stop looking identical.

One code per place you post. The numbers do the rest. Start free at botable dot I O.

Everything said in the video, in order.

Nobody finds a Telegram bot by browsing. Your first hundred users all arrive from a link you posted.

So the work is choosing where to post, giving people a reason to press start, and learning which post worked.

Your bot's public address lives in Manage, under Bring people in, with a copy button — a mistyped username is a link that silently goes nowhere.

The QR beside it encodes that same address. It earns its place on a slide, a flyer or a table tent, where a phone is out and a keyboard is not.

A bare link converts badly. The description in Telegram Settings is the sentence Telegram prints on the empty chat, before anybody has pressed start, so write it for the reader.

Two lines here: blue is messages that day, green is how many separate people sent them. A channel that worked shows up as a step in the green.

Narrow the window to seven days to see whether yesterday's post moved anything. Growth, underneath, counts twelve people whose first message came this week.

Post that link in five places and all five arrivals look identical here. Add a start code to each one and ask the builder to store it, and every arrival names its source.

Give them a reason, and give each channel its own code. Start free at botable dot I O.

Everything said in the video, in order.

A support bot is a queue, not a conversation. Something breaks, it gets a row, and somebody works through it.

Botable builds that from one description, and every ticket lands in a table the bot owns.

This is the prompt that built Lumen Support. Three sentences, no schema and no handler names, only what a person should be able to do.

Name the actions and the branch. Open a ticket, choose billing or technical, check status, read the FAQ, reach a human. Each one becomes a screen.

The Flow tab reads the finished bot back out of its own code. Main flow starts at slash start and follows the buttons a person would actually press.

Each card is a screen someone lands on. Billing and technical became separate handlers, so a branch you asked for in one clause is a real fork in the bot.

Nothing was configured for storage. The bot creates a tickets table on its first run, and the Database tab opens the same file the bot writes to.

Eighteen rows, one per ticket, with topic, subject, status, priority and the agent who has it. That is a desk you can query, not a transcript.

Three sentences in, a working ticket queue out. Start free at botable dot I O.

Everything said in the video, in order.

Five questions make up most of what anyone asks you. A bot can answer those five, forever, at any hour.

The answers are the easy half. Learning which of them people actually reach for only happens after launch.

Name the five questions you already answer by hand. Five is the useful number: enough to cover the volume, few enough to fit one screen.

Ask for one inline button per question, and for the answer to replace the menu in place. Tapping beats typing, and the chat stays one message deep.

Once it is live, Manage then Audience ranks every command and button the bot handled, counted from real traffic. You instrument nothing.

The FAQ menu was opened twenty three times. Billing, one of the answers behind it, twenty. Those two are carrying the whole feature.

An answer that never surfaces in this ranking is one almost nobody opens. Either the label does not say what people expect, or the question was never asked.

So the next revision runs on evidence. Promote what gets pressed, reword what does not, and ask for it without leaving the numbers.

Answer the five, then let the presses tell you which five. Start free at botable dot I O.

Everything said in the video, in order.

A waitlist bot has one job: get a way to reach someone later, out of a chat they already opened.

Telegram gives your bot a name, a username and a number. Never an email, never a phone. You have to ask.

Describe the capture, not the code. One button, one question, one place to put the answer. The builder writes the handler and the table.

A phone is different. Telegram has a keyboard button that shares a real contact on one tap, and it works only inside a private chat.

Answers land in the bot's own SQLite file. The Database tab is a window onto it, and whatever table your bot created appears in this list.

Open one and you see exactly the columns your bot wrote. Telegram ID leads the table in bold. Keep the address beside it, because that number never changes.

Manage, then Audience, is your side of that list, and these are real people. Say what you are collecting for before you take an address, and build a way off it.

Export writes those people out as CSV or Excel: name, username, and the Telegram ID. The addresses stay in your own table, joined to them on that ID.

Ask once, store it with the ID, keep a way out. Start free at botable dot I O.

Everything said in the video, in order.

A shop taking orders in chat needs three things from a bot: a menu, a cart that adds up, and a confirmation.

All three come from one prompt. What decides it is the wording, the kind of buttons, and where orders land.

Describe the whole path in one message: the menu and what it costs, what a tap does to the cart, and what Checkout should do once somebody has finished ordering. One message, not three.

Then the part people leave out: what happens after Checkout. An order nobody is told about is a row in a table quietly going cold.

Inline buttons live inside the message they arrive with. A tap sends a silent callback, so the bot can rewrite that same message instead of posting a new one.

Which is what a cart wants: one message that adds up in place. The Flow tab draws whatever your bot becomes — the menu on top, each button that leads somewhere leaving on its own thread.

Orders end up as rows in the bot's own SQLite file, with no database to set up. The Database tab opens that file and lists whatever the bot created.

This demo bot writes tickets; yours writes orders. Same shape — a row each, a status column, and the time it came in.

A menu, a cart in one message, a row for every order. Start free at botable dot I O.

Everything said in the video, in order.

Two people open your booking bot, tap the same Thursday at three, and both of them get told yes.

Nothing about that is Telegram's fault. It comes down to where your bot checks the slot is still free.

Describe the service, not the code. Your hours, how long one slot runs, how far ahead people can book, and the fact that each booking is a stored row.

Then the half everyone forgets. A confirmation that repeats the date back, and a way to cancel, or you get a bot that takes slots and never frees one.

Every tap reaches the bot in the log as its own update, long after the list was drawn. Telegram never refreshes that message, so it stays a snapshot.

So do not trust the tap. Ask for a unique index on date and time. The second write then fails inside SQLite, and that person is told, not booked.

Bookings are rows in the bot's own SQLite file. The Database tab opens that file, listing every table the bot created next to its row count.

This table carries a status column, and yours should too. But a cancelled row still holds its slot, so the unique index has to skip the dead ones.

Show the slots, store the booking, let the table say no. Start free at botable dot I O.

Everything said in the video, in order.

A daily digest is the easiest useful bot to build, and it is also the easiest one to get muted.

The recipe is a prompt that names the hour, a scheduler that lives inside the bot, and a send nobody has to hear.

Say the job in plain words. Start with the time, and name a timezone — without one the schedule follows the server's clock, not yours.

Then who it reaches, and when to stay quiet. A digest that arrives with nothing in it spends goodwill you need on the days that matter.

The clock runs inside your bot. node-cron ships with the runtime, so nothing is installed, and your job registers where the log says the bot started.

Audience counts everyone who has ever messaged the bot, which is the wrong list for a daily push. Send to people who opted in, and let them opt out.

Botable paces its own broadcasts. Fifty-three people is fifty-three separate calls, and a digest loop is your code — leave a gap, or Telegram refuses past about thirty a second.

Telegram never tells you that someone muted you. They go quiet, then they block. A digest is exactly the message to send without a sound.

Only to people who asked, only when there is news. Start free at botable dot I O.

Everything said in the video, in order.

A quiz is five questions and a right answer. The part that makes it a bot is remembering the score.

Telegram hands your bot one update at a time and remembers nothing between them. The score is yours to keep.

Describe the round, not the loop. Say how many questions, that answers are buttons, and that a point lands on the person who tapped it.

Buttons, not typed answers. A tap sends back a value you chose, so scoring is a lookup instead of guessing what someone meant by yeah.

A variable holding the score survives until the next reload, and every change you ask for reloads the bot. The table survives all of it.

This bot already keeps a row for every FAQ view. Answers work the same way, one row each, and the rows tell you which question everyone gets wrong.

The totals sit one table over. One row per person, keyed on the Telegram I D, with a counter beside it that climbs the more they use the bot.

The leaderboard is one query: order by score, highest first, take ten. Break ties on who reached it first, or the order of equal scores is arbitrary.

A row per player, one query for the board. Start free at botable dot I O.

Everything said in the video, in order.

Some answers are not yours to write down. A price, a stock level, whether the service is up right now.

So the bot goes and gets it. What matters is how you ask, where the key goes, and how often you call out.

Describe the answer and where it comes from. Not the endpoint, not the library — the moment in the conversation, and the source that settles it.

When the source needs a key, the agent asks for it here instead of sending you to a settings screen. It reads what is already set before it asks.

All that is left in the thread is one line holding the key's name. The value you pasted never comes back to the agent, and it is wiped from the run once saved.

It goes into this bot's own environment file on the server, and the code refers to it by name, so the key is never a literal in a source file.

Call out on every message and one busy hour is hundreds of identical requests — enough for the source to throttle you, or bill you. Ask for a cached copy instead; this weather bot keeps one.

A table in the bot's own database, and every row is stamped with the moment it was fetched. A fresh row is served as it stands; a stale one sends the bot back out.

Ask plainly, hand the key over once, cache what comes back. Start free at botable dot I O.

Everything said in the video, in order.

A paid community is two problems. Taking the money, and letting only the people who paid through the door.

Stars settles the first. The second is one entitlement check your bot runs before it hands anything over.

Payments is the last row of the Manage rail. A tier is a price in Stars, monthly or one-time, plus trial days. Pro here is two hundred and fifty a month.

The features box is the gate. Its label names the call, plans dot can, and whatever you list in the box is what that call answers yes to.

A new tier lands at one hundred Stars a month. Name it, then give it the one key that means membership, and the Save button turns into Save and wire up.

Saving hands the list to your builder, so tell it where the gate goes. Telegram mints that link only if the bot is an admin allowed to invite.

Trial days above zero is what earns a try-free button. And billing is not cosmetic: monthly opens as a subscription link, one-time as a plain invoice.

Every payer lands in Customers with the plan they hold and whether it still renews. Canceling keeps their access until the period they paid for ends.

Price the door, hold one key, check it before you open. Start free at botable dot I O.