Parcel delivery service: a RAG support assistant on Telegram

TL;DR. A RAG assistant on Telegram over a 550-document knowledge base — tariffs, delivery times, terminology, pickup and handover procedures, returns. A customer gets an instant answer to a routine question; when the bot can't help, the conversation goes to a human operator with the chat history intact.

For how this works under the hood, see the RAG assistant guide.

Situation

The delivery service's support team fielded the same questions on repeat: how to send a parcel, what it costs and how long it takes, what terms like "shipment" mean, how pickup and handover work, what to do about a return. The answers lived scattered across internal regulations and operators' memory — routine questions ate up operator time that would be better spent on the non-routine ones.

Task

1. Answer routine customer questions on Telegram from the regulations and tariff knowledge base, without waiting for an operator.
2. Hand a conversation off to a human operator when the bot can't help, without losing the chat history.

What we built

A RAG assistant on aiogram over a 550-document knowledge base (regulations, tariffs, FAQ), indexed in PostgreSQL with pgvector. The first message shows the customer the range of topics the bot covers — sending a parcel, delivery times and cost, terminology, pickup and handover, returns and storage — after that the customer just types a question in plain language.

Escalation to a human operator happens on an explicit customer request ("Operator" or a similar phrase): the bot forwards the conversation to the support queue and tells the customer someone will be in touch shortly. Dialog context is kept in Redis, so the operator sees the conversation history instead of starting from zero.

Result

• Routine questions get closed by the assistant instantly, with no wait for an operator.
• 2-3K enquiries a month go through the bot; a share of them escalate to an operator with the dialog context preserved.
• In production since September 2025.

Key technical decisions

1. pgvector instead of a dedicated vector database. With a 550-document base, a separate vector engine is overkill — pgvector reuses the PostgreSQL instance already in the stack instead of adding another service to the infrastructure.
2. Redis for dialog context. An escalation to a human operator needs the conversation history, not a fresh start — dialog state lives in Redis and travels with the handoff.
3. aiogram instead of a no-code builder. Escalation logic and dialog state need real code, not a chain of nodes — conditional branching like this gets brittle fast in a no-code tool.

FAQ

Does the bot answer questions about a specific parcel — where it is right now?

No, in this version the bot answers questions from the regulations knowledge base: tariffs, delivery times, terminology, pickup and handover procedures, returns. Questions about the status of a specific shipment would need a separate integration with a tracking system, which the bot isn't wired into yet.

How does the bot know when to hand off to an operator?

On an explicit customer request — a command like "Operator" or a similar phrase moves the conversation into the support queue. The bot doesn't try to guess how hard the question is on its own; that call always stays with the customer.

Why GPT-4o mini rather than a larger model?

A 550-document base and routine support questions don't need a model with a huge context window or heavy reasoning — a compact model answers faster and cheaper at comparable quality for this scope of work.

What would come next

The natural continuation is integrating a tracking system, so the bot answers not just general delivery questions but also the status of a specific shipment by its number.

If you have a similar problem — a support team drowning in the same questions on repeat — let's talk it through in 30 minutes.