Telegram bot cost in Uzbekistan: workflows and an itemised estimate

A bot with a few buttons and one that takes an order, checks data and hands a conversation to an operator may look similar. Their cost follows what happens after a tap. Before requesting a price, describe the main task and result: collect a contact, answer a question, create a request or complete a sale. Add exceptions and the employee’s work next. This guide helps build a comparable estimate; a general Telegram-store overview cannot replace scoping the actual business process.

1. Distinguish support from commerce

A support bot does not necessarily need a cart or payment module. A commerce bot needs orders and exceptions even when its messages are short. Define where the task is complete and who takes responsibility next. If one bot combines several processes, estimate each before identifying shared components. This reveals what can ship first and what remains manual. Calling something an “AI bot” does not describe its functionality or price, and a button count does not describe the underlying work.

2. Break the solution into components

Include conversations, data handling, storage, integrations, administration and testing. Specify who edits answers and rules after launch. If every change needs a programmer, that creates an operating cost. Provide sample requests and questions the bot must not resolve independently. For CRM, define fields, duplicates and an owner during outages. For support, specify operator hours, queues and how a conversation resumes. A connection existing does not prove that data reaches the right employee, so its business outcome belongs in the acceptance criteria.

3. Choose an interface for the task

Commands and buttons suit sequential actions; a Mini App may help with a complex form or large catalogue. Test a simple prototype with future staff and users first. Do not add another interface just to look modern. Agree languages, cancellation, back navigation and human handover. If AI is used, define answer sources, authority boundaries and quality criteria. A model should not confirm an unknown price or change an order merely because a user requested it. Include these limits in both design and testing.

4. Identify what is being paid for

Telegram distinguishes physical goods and services from digital goods sold inside its applications. Digital goods and services sold through bots and Mini Apps within Telegram use Telegram Stars. Do not automatically apply a physical-store payment design to digital access. Before estimating the chosen approach, check platform conditions, provider availability and merchant-account readiness. Include confirmation, repeated notifications, cancellation and buyer support in the work. Fees and approvals remain separate external-service terms rather than assumptions that a developer can guarantee on your behalf.

5. Compare work and dependencies

Calculate agreed components and their effort, work cost, one-off external services and operating costs separately. This is a comparison formula, not a new SAMSA.AGENCY tariff. As an illustration, compare one language and manual operator assignment with two languages and department routing. The latter adds states and checks without necessarily doubling the whole project. Request included revisions, exclusions and required business materials. A commerce solution: https://samsa.agency/en/solutions/telegram-bot ; automation and AI: https://samsa.agency/en/services/ai-automation.

6. Accept ordinary and error workflows

1. A new user understands the purpose, starting action and help.
2. Incomplete input can be corrected without losing completed fields.
3. Repeated actions do not create unnecessary requests or orders.
4. An unavailable integration gives a clear next step.
5. Human handover delivers history to the right employee.
6. An operator sees only permitted data and can update the state.
7. Recovery preserves required enquiries and settings.

For AI, prepare questions with an expected answer, unknown facts and attempts to exceed authority. Acceptance checks quality and human escalation rather than generation speed alone. Commerce must also pass agreed payment-error tests. Record results and unresolved limitations: they define readiness for the chosen scope, not a promise that future incidents will never happen.

7. Define handover and support

Account separately for hosting, paid APIs, model usage, storage, monitoring and content changes. Do not promise employee replacement or fixed payback: measure actual enquiries and handling time first. Agree transfer of the bot account, code, instructions and recovery process, then name an owner and incident contact. Bulk messaging, voice, complex catalogues and new integrations do not automatically belong to a basic workflow. Each expansion needs a separate purpose and acceptance criterion, with its ongoing costs visible to the business.

Official sources checked on 14 October 2026: bot features — https://core.telegram.org/bots/features ; physical goods and services — https://core.telegram.org/bots/payments ; digital goods — https://core.telegram.org/bots/payments-stars . Verify the selected provider and actual merchant-account requirements separately before launch.