Telegram Bot Funnel Build with Payments and CRM Handover

A Telegram bot cannot message anybody who has not started it. Every other decision in this build follows from that sentence. It means Telegram has the strictest consent model of any channel we work in, which is the good news, and it means the acquisition problem is the whole problem, which is where most builds fail. Teams arrive wanting a conversational funnel and leave understanding that the funnel is fine and the traffic into it does not exist. So we design the entry before the conversation. Deep links carry a start payload of up to sixty-four characters, which is enough to encode source, campaign and the position on a landing page where the user tapped. That payload is the only attribution you will ever get, and it has to be minted at link-creation time by whatever generates your ads, emails and QR codes. Retrofitting attribution onto a live bot is a rebuild, so this is settled in week one. What the build contains: Bot on the Bot API with webhooks on your infrastructure, not long polling on somebody's laptop. Conversation state persisted in Postgres, so a user who disappears for a week resumes rather than restarts. Inline keyboards on every branch, because free-text parsing inside a funnel produces support tickets and nothing else. Telegram Payments where money changes hands, with Stars for digital goods and a provider token for physical ones, and the refund path built at the same time as the checkout rather than after the first dispute. Broadcast, paced: The API's rate limits are unforgiving of naive loops, and a broadcast written as a for-loop over user IDs gets throttled partway through with no record of who received what. We build the broadcast layer as a queue with per-chat pacing, retries on the specific errors that warrant them, and a permanent delivery state per user, because a message you cannot prove was delivered cannot be sequenced against your email programme. Identity handover: A bot knows a Telegram user ID and nothing else. Email or phone arrive only if the user hands them over, and we build that as an explicit step with a stated reason, not a silent contact-request button harvesting a number in exchange for a discount code. The handover writes into your CRM as the same person record the email programme uses, and from that moment suppression is shared. Skip this step and you have built a second, disconnected database of strangers. Data and consent: What the bot stores, for how long, and how a user erases it, documented before launch. In Czech and EU deployments that is a Telegram user ID, a position in the state machine and whatever the user volunteered, removable on a delete command that actually deletes rather than flagging. We refuse: Token, airdrop and any crypto referral funnel. Betting and gambling funnels of any description. Tap-to-earn and referral-multiplier mechanics, which produce a subscriber count and no customers. Purchased channel subscribers or bot starts from a boost market, which we can usually detect in an existing bot's cohort data and will point out before declining. Not included: Community moderation. Channel content strategy and the writing of posts. Mini App visual design beyond a functional interface, though we build the Mini App itself in the top package. Languages beyond English and Czech. Who this is not for: Brands with no existing Telegram audience and no plan to buy traffic into one, because the bot will sit at a few hundred starts and disappoint everybody who approved it. Teams who want the bot to replace a support desk. Regulated medtech and pharma work, which we do elsewhere but not here, since Telegram gives us no acceptable place to put health data.