Telegram as universal interaction surface
Notifications in Slack, approvals in email, feedback in Intercom — small teams context-switch all day. One Telegram bot routes everything.
What
Use one Telegram bot as the single point of contact between your internal automation and your team: notifications (deal alerts, build failures), inbound (forward me a deck, I'll process it), daily reminders (you have 3 unswiped founders today), owner approvals (thumb up to ship this code change), feedback collection (DM the bot about the swipe UI). One bot ID, multiple message kinds routed by content. Telegram replaces Slack, email, intercom, and ad-hoc dashboards for a small team.
Why it matters
A founder-discovery CLI and a deal-intake bot share a single bot (@yourbot), with the intake bot polling getUpdates and the source bot using sendMessage only (no polling contention). Practical experience: small teams use Telegram constantly anyway; building automation surfaces inside it removes context-switching. The notification → action → followup loop runs in one app.
End-to-end
- BotFather → new bot → token in
TELEGRAM_BOT_TOKEN. - One process polls
getUpdates(only one process can do this; pick the one that needs to receive messages). - Other processes use the Bot API's
sendMessageonly — no contention. - Route inbound by content: URL → ingestor; PDF → deck handler; plain text → freeform processor.
- Owner approval flows: send message + inline keyboard (thumb up / thumb down); persist the approval state in your DB; on thumb-up, run the next step.
- Daily reminder cron: send templated nudges with progress numbers ("you swiped 3 of 10 today").
- Per-user state via
user_email(ortg_user_id) columns — multi-tenancy without auth gymnastics.
Gotchas
- Two processes polling
getUpdatescause silent message loss. Pick one polling owner; everything else usessendMessageor a separate bot.
Variations
- Region-specific multi-channel variant. When operating in regions where Telegram alone doesn't reach all customers (e.g. multiple regional messengers + WhatsApp + Telegram), wrap the universal surface in a per-channel adapter layer. Customer-facing: a CRM + Telegram + the regional messenger(s) routed into one queue (see B-028 merge). Internal-facing: keep Telegram as the operator's primary surface but accept that customer-side coverage requires multi-channel adapters.
Tools
- Telegram Bot API token
- A web server with one polling process
- SQLite or any DB for state