← HomeРусская версия

Case study · Client project

STOKCEN — customer intake and sales workflow

An appliance retailer’s customers ask for help choosing an oven, a dishwasher or a TV. I built the workflow that turns such a request into a structured brief for a store manager, gets an offer back to the customer and keeps the conversation attached to the request.

My role
End to end for the client: workflow design, architecture, implementation, testing and deployment
Status
In production for the client; first version February 2026, current version September 2026
Format
Telegram bot, Mini App and a web dashboard; interface in Russian
Open the bot

Context and problem

The client sells household appliances through several stores. Customers ask for help choosing: a built-in oven of a certain width, a dishwasher for a specific niche, a TV of a certain size. Such a request is useful only if it arrives complete — dimensions, installation and connection type, colour, an approximate budget.

It then has to reach a manager of the right store quickly, come back as a concrete offer and stay a conversation after the first answer, not a lost chat thread. The request is for help choosing, not a purchase: the customer confirms a preference and asks to be contacted. No payment or reservation is involved.

Understanding

The core problem was not chat but structure and ownership. A free-form message cannot be compared, routed or reported on, and a request that no single manager owns gets answered twice or not at all.

So the product had to do three things: ask the right questions for each kind of appliance; give every request exactly one owner; and keep the offer and every later message attached to that request — while the business owner can see where requests wait.

MVP and scope

In
Step-by-step intake for each appliance category, built from configuration. One open request per customer. Routing by store and a single Take button. Offers with models, prices and alternatives. Status updates for the customer. Roles and an admin panel in Telegram. A read-only dashboard for the business owner.
Out
Payments and reservations, stock and CRM integration, AI features. The value was a reliable workflow, not automation for its own sake.

What I built

  1. IntakeIn Telegram the customer chooses a store and an appliance category and answers questions one at a time: dimensions, installation and connection type, colour, an optional budget. Any question can be skipped.
  2. Structured requestBefore sending, the customer reviews the request as a draft and can edit or remove items. Each customer has one open request; a new one replaces the old.
  3. RoutingEvery manager of the chosen store gets the request with a Take button, and the first to press it owns the request. If a store has no managers, supervisors and then admins receive it.
  4. OfferThe manager adds a model and a price for each item, can offer alternatives or mark an item out of stock, and sends the offer. A sent offer is never edited; a correction goes out as a new revision.
  5. ConversationIn the Mini App the customer picks options and confirms. Customer messages to the bot are attached to the request, and the manager answers from the Mini App.

The business owner manages people, roles, stores and broadcasts in a Telegram admin panel, and sees requests by status, a comparison of stores and the average time to take a request in a read-only web dashboard.

The first version as a diagram: customer → step-by-step dialogue → routing → notification to a manager → take → model and price → offer → status updates; the business owner sees a dashboard and an admin panel. Labels are in Russian.

My ownership

Built by me
The whole product for the client: workflow and data model, architecture, backend, the Telegram bot and the Mini App, routing, notifications, the customer–manager conversation, the dashboard, tests and deployment.
The client
The business itself: stores, staff, the appliance range and the parameters that matter for each category. Permission to show the project here.

Key decisions

Store-based routing with an atomic Take
A request goes to all managers of the selected store, and the first to take it becomes its owner. Taking is one conditional database update, so two managers can never own the same request.
Offers are versioned, never edited
A sent offer does not change; a correction is a new revision. The customer and the manager always refer to the same version, and the history stays readable.
SQLite and an outbox instead of more infrastructure
For restart-safe state and reliable notifications I rejected Redis and a separate database server as more than the load needed. Durable rows in SQLite and an in-process outbox were the smallest sufficient design: the bot is the only writer, and the dashboard reads the database in read-only mode.
Simple, revocable Mini App sessions
The Mini App verifies Telegram’s signed launch data once and then uses an opaque session cookie stored only as a hash; a role or store change revokes it. JWT, refresh tokens and longer-lived launch data were rejected.
The bot stays as a fallback
When the Mini App reached feature parity, the bot was kept as a reserve path instead of being removed.

Constraints, mistakes and trade-offs

  • An internal review of the early version found several issues with access control and concurrent request handling. All were fixed before the next stage — the Mini App.
  • One writer process on SQLite is a deliberate limit: enough for a few stores, not a multi-instance setup.
  • The workflow runs inside Telegram, so it depends on Telegram’s platform and delivery.
  • Releases are accepted in a browser at Telegram-sized widths with synthetic data; testing on physical phones is not part of the release process yet.

Validation and testing

  • About 300 backend tests and over 100 Mini App tests.
  • Every release is built in isolation, reviewed independently before it goes live, checked in a browser at 320–430 px in light and dark themes with synthetic data, and verified after deployment.
  • A rollback is prepared before each release; old database backups are never restored as a routine rollback.

Deployment and real status

In production for the client. Development started in February 2026; the web dashboard followed in April, roles and stores in August, the Mini App at the end of August and the customer–manager conversation in September 2026.

The Telegram bot is public; the Mini App and the dashboard serve the client’s customers and staff. There are no public business metrics for this project.

What I would improve next

  • Review the time-to-take figures from the dashboard with the client, store by store, to see where requests wait.
  • Connect stock and prices from the client’s systems, so managers stop typing models and prices by hand.
  • Add physical-phone checks to every release.

Tech summary

Bot and API
Python, aiogram 3, aiohttp; one process serves the bot and the Mini App API
Mini App
React 18, TypeScript, Vite; tests with Vitest and Testing Library
Data
SQLite with additive migrations; a durable notification outbox
Dashboard
Streamlit, read-only, behind authentication
Auth
Telegram launch data verified by HMAC, opaque revocable session cookies
Infrastructure
Docker Compose; the static Mini App behind nginx

Want to talk about work like this?

Email or Telegram — I am happy to walk through any of the decisions above.

vitalii@inin.ceoTelegram @inin_ceo

← Swipe →