How I Built a Production Multilingual Telegram Support Bot in Under a Week

Lin Jacky — Mon, 09 Mar 2026 04:57:14 +0000

A prediction market platform operating across Southeast and South Asia came to me with a straightforward problem:

"We need 24/7 customer support in multiple languages. We can't afford a full support team right now."

My answer: one bot, one week, zero human agents on standby.

Here's exactly how I built it — and the architectural decisions that made it actually work in production.

The Requirements

Before writing a single line of code, I scoped it down hard:

Handle the 10 most common support questions (not everything)
Support Chinese and English, auto-detected
Clean handoff to a human when the bot can't help
Ops-friendly: the team needs to monitor it without being engineers
Deploy on Zeabur VPS — their existing infrastructure

That last constraint shaped almost every technical decision that followed.

Architecture: Why I Chose Single-Process Over Microservices

The instinct for many engineers is to reach for microservices — separate containers for the bot, the HTTP server, the scheduler, the log analyzer.

For a lean startup team, that instinct is wrong.

Here's why I went single-process instead:

┌─────────────────────────────────────────┐
│              Single Process             │
│                                         │
│  ┌─────────┐  ┌──────────┐  ┌───────┐  │
│  │Telegram │  │   HTTP   │  │ Cron  │  │
│  │   Bot   │  │  Server  │  │Sched. │  │
│  └────┬────┘  └────┬─────┘  └───┬───┘  │
│       │            │            │       │
│  ┌────┴────────────┴────────────┴────┐  │
│  │         Log Analyzer             │  │
│  └──────────────────────────────────┘  │
└─────────────────────────────────────────┘

One thing to monitor. One thing to restart. One thing to debug at 2AM.

With microservices, you trade deployment flexibility for operational complexity. For a team of 2-3 people, that's a bad trade.

Key Components

1. Multilingual Detection

Rather than asking users to pick a language, the bot auto-detects:

def detect_language(text: str) -> str:
    """Simple heuristic: check for CJK characters."""
    cjk_count = sum(1 for char in text if '\u4e00' <= char <= '\u9fff')
    return "zh" if cjk_count / max(len(text), 1) > 0.2 else "en"

Simple, fast, works for 95%+ of real-world inputs. No external API needed.

2. Response Routing

INTENT_MAP = {
    "deposit":     ["deposit", "fund", "topup", "入金", "充值"],
    "withdraw":    ["withdraw", "cashout", "提款", "提現"],
    "account":     ["account", "login", "verify", "帳號", "登入", "驗證"],
    "market":      ["market", "bet", "predict", "市場", "投注", "預測"],
    "handoff":     ["human", "agent", "support", "真人", "客服人員"],
}

def route_intent(message: str) -> str:
    msg_lower = message.lower()
    for intent, keywords in INTENT_MAP.items():
        if any(kw in msg_lower for kw in keywords):
            return intent
    return "fallback"

The fallback state is critical — more on this below.

3. Hourly Log Rotation

Bots that run continuously accumulate logs fast. Without rotation, you're debugging a 2GB file at 3AM.

import logging
from logging.handlers import TimedRotatingFileHandler

handler = TimedRotatingFileHandler(
    "bot.log",
    when="h",        # rotate every hour
    interval=1,
    backupCount=24   # keep last 24 hours
)

This keeps the system lean and makes log analysis actually usable.

4. The Dashboard

The ops team is not engineers. They needed visibility without touching the terminal.

I built a lightweight Chart.js dashboard served directly from the same process:

from http.server import HTTPServer, BaseHTTPRequestHandler

class DashboardHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/dashboard":
            stats = analyze_logs()  # parse last 24h of logs
            html = render_dashboard(stats)
            self.send_response(200)
            self.end_headers()
            self.wfile.write(html.encode())

Metrics shown:

Messages handled (last 24h)
Intent distribution (what are users asking?)
Handoff rate (how often does the bot fail?)
Response time average

The Most Important Design Decision: Failure States

Most chatbot projects obsess over the happy path.

The bots that actually get used are designed around what happens when things go wrong.

In our case, the fallback flow looks like this:

User message
    ↓
Intent detected? → YES → Send response
    ↓ NO
Confidence score > threshold? → YES → Best-guess response + "Was this helpful?"
    ↓ NO
→ "I'm connecting you with a team member. Expected wait: [X] mins."
→ Log to handoff queue
→ Notify human agent via separate Telegram channel

The handoff notification to the human agent was a last-minute addition.

It turned out to be the feature the ops team used most.

Deployment on Zeabur

Zeabur makes single-process Python deployments straightforward:

# zeabur.yaml
build:
  command: pip install -r requirements.txt

start:
  command: python main.py

Environment variables managed through Zeabur's dashboard — no .env files in production.

Total deployment time from first push to live bot: under 10 minutes.

Results

Live in: 6 days from initial scoping call
Languages supported: Chinese (Traditional/Simplified) + English
Human agents needed on standby: 0 (during off-hours)
Handoff rate: ~18% of conversations (within acceptable range for the use case)
Uptime since launch: 99.7%

The ops team checks the dashboard once a day. That's it.

What I'd Do Differently

1. Add a proper NLP layer sooner

The keyword-matching intent router works, but it fails on typos and informal language. A lightweight model (even fasttext for language detection) would improve accuracy significantly.

2. Separate the handoff queue from the main process

The current implementation handles handoffs in-memory. For higher volume, this should be a proper queue (Redis or even a simple SQLite table).

3. Build the dashboard before the bot

Counterintuitive, but the dashboard forced clarity on what metrics actually mattered. I'd start there next time.

Takeaways

If you're building support automation for a lean team:

Narrow scope wins. 10 questions done well beats 100 questions done poorly.
Design for ops, not just users. If your team can't monitor it, they'll abandon it.
Single-process is not a cop-out. It's often the right architectural choice for early-stage products.
The handoff is a feature, not a failure. Build it like one.

I build AI-powered automation systems for startups — chatbots, pipelines, and infrastructure that lean teams can actually maintain. If you're working on something similar, feel free to connect.

Discussion prompts for comments:

How do you handle multilingual bots at scale?
What's your threshold for switching from keyword matching to ML-based intent detection?
Anyone else using Zeabur in production? How's your experience?

DEV Community: Lin Jacky