- 30 Apr 2026
- Booking & Payments
- 7 min read
How to Handle Cancellations and Refunds Without Manual Work
A client cancels a tour three days before departure. Now what? In most agencies, the answer involves a chain of manual steps: someone notifies the accountant, the accountant calculates what's owed, an agent writes to the client, the director approves the refund, and eventually someone logs into online banking and makes a transfer. The client waits two to four days — sometimes longer — wondering whether the money is actually coming. By the time it arrives, they've already told two friends how difficult your agency is to deal with.
Cancellations are unavoidable in travel. Flights get cancelled. Visas get denied. Family emergencies happen. What determines whether a cancellation damages your agency's reputation is not the cancellation itself — it's how fast and how cleanly you handle it. This article walks through every component of a modern, automated cancellation and refund workflow: what to define upfront, how to set up the CRM flow, how digital refunds work via Click and Payme, and why every cancellation needs a logged record.
"A cancelled booking is not the end of the relationship. A slow, confusing refund process is."
Why Manual Cancellation Handling Fails
The problem with a manual cancellation process isn't that people are careless — it's that the process depends entirely on people remembering, communicating, and calculating correctly, without any system to catch errors or enforce steps. Here's what routinely goes wrong:
- Calculation errors. Different agents apply different cancellation percentages. There's no single source of truth for the policy.
- Delays from approval chains. The accountant needs the director's sign-off. The director is in a meeting. The client waits and calls again.
- No audit trail. When a client disputes the refund amount a month later, nobody can find the original cancellation record or who approved it.
- Booking status not updated. The seat or room remains marked as occupied in your system, blocking new sales until someone notices and fixes it manually.
- Client left in the dark. No automatic notification means the client doesn't know the cancellation has been received or when to expect the refund.
Each of these failures is predictable and preventable. The solution is not to hire more careful people — it's to replace the manual process with a structured, automated workflow.
Define Your Cancellation Policy Before Anything Else
Automation can only work consistently if there is a clear policy to automate. Before touching your CRM configuration, you need a written cancellation policy that defines exactly what percentage is refunded at each stage. A typical structure for tour agencies in Uzbekistan looks like this:
| Cancellation Timeframe | Refund Amount | Notes |
|---|---|---|
| 30+ days before departure | 100% refund | Minus booking processing fee (if any) |
| 15–29 days before departure | 75% refund | 25% cancellation fee retained |
| 7–14 days before departure | 50% refund | Deposit typically non-refundable |
| 3–6 days before departure | 25% refund | Only portion above non-refundable costs |
| 0–2 days before departure | No refund | Full cancellation fee applies |
This policy should appear in your booking confirmation documents, on your booking confirmation page, and ideally as a checkbox the client acknowledges before payment. When this is in place, the refund calculation becomes a formula — not a judgment call — and your CRM can apply it automatically based on the departure date stored in the booking record.
Automating the Cancellation Flow in Your CRM
Once your policy is defined, the CRM can handle the entire operational sequence without agent intervention at each step. Here is what the automated flow looks like:
Client or agent initiates cancellation
Either the client submits a cancellation request through a form on your booking confirmation page, or an agent marks the booking as "Cancellation Requested" in the CRM. Both paths feed the same workflow.
CRM calculates refund amount automatically
The system reads the departure date from the booking record, calculates the number of days remaining, applies the matching policy tier, and displays the refund amount to the agent for confirmation — no manual arithmetic required.
Booking status changes to "Cancelled"
Upon confirmation, the booking card moves to "Cancelled" status. The seat or room is released immediately in your availability system. The booking history is preserved with a timestamp and the agent who actioned it.
Client receives automatic cancellation notification
A templated message fires immediately via Telegram or email: "Your booking [reference] has been cancelled. A refund of [amount] will be processed to your Click/Payme account within 1–3 business days." The client knows immediately — without calling to ask.
Refund task is created and assigned
A refund task appears in the accountant's queue in the CRM, pre-populated with the booking reference, client name, payment method, original transaction ID, and the calculated refund amount. One click to open the Click or Payme merchant dashboard and process it.
Refund Processing via Click and Payme
If the original payment was made through your Click or Payme merchant account — which it should be, for exactly this reason — the refund is straightforward. You do not need to initiate a bank transfer, obtain the client's card number again, or ask the client for any additional information.
How it works digitally: Both Click and Payme allow merchants to initiate a reversal directly from the merchant dashboard or via API, referencing the original transaction ID. The refund is credited to the same account or card the client used for the original payment. Typically, the funds appear within one to three business days depending on the provider and the client's bank.
Via the merchant dashboard (no API): Log into Click Business or Payme Business, locate the transaction by reference number or date, select "Refund," enter the amount, and confirm. That's it. The entire process takes under two minutes per transaction.
Via API (automated): For agencies processing more than 15–20 cancellations per month, the CRM can call the Click or Payme API directly when the accountant clicks "Process Refund" in the task queue. No browser login required — the refund is initiated programmatically and the transaction status is written back to the booking record automatically.
The critical point: if the original payment was collected as a personal card transfer, none of this is possible. The agency has no formal refund mechanism — only a manual bank transfer with no connection to the original payment, no automatic record, and no protection in a dispute. This is the strongest practical reason to move all payment collection through your merchant accounts.
Handling Partial Refunds: Deposit Kept, Balance Returned
Many agencies collect a non-refundable deposit at booking — typically 20–30% of the tour price — and the remainder closer to departure or upon full payment. When a cancellation occurs after the deposit has been paid but before the balance, you need to return only the balance portion while retaining the deposit.
In practice this means: if a client paid a 30% deposit of 3,000,000 UZS and later paid the 70% balance of 7,000,000 UZS, and then cancels within the 50% refund tier, the calculation is: total paid is 10,000,000 UZS, 50% refund is 5,000,000 UZS, minus the non-refundable deposit of 3,000,000 UZS already retained, so the actual transfer back to the client is 2,000,000 UZS.
Your CRM should store each payment transaction separately — deposit payment, balance payment — linked to the booking. When a cancellation is processed, the system references all linked transactions and calculates the net refund across all payments. Both transactions can be partially reversed via Click or Payme against their respective original transaction IDs. The client receives one clear message showing what was paid, what is being retained, and what will be refunded — with no room for confusion about the arithmetic.
A partial refund calculation done manually by memory is how disputes start. A partial refund calculated by the system from stored transaction records, shown to the client in writing, is how disputes end before they begin.
Logging and Audit Trail: Every Cancellation Must Be Recorded
Every cancellation that goes through your system should generate an immutable log entry. This is not about bureaucracy — it protects your agency in three very real situations:
The minimum fields every cancellation log entry should contain: booking reference, client name, original booking amount, cancellation date, departure date, days-to-departure at cancellation, policy tier applied, refund amount calculated, refund amount approved, payment method, original transaction ID(s), refund transaction ID(s), and the agent who actioned the cancellation. All of this should be generated automatically by the CRM — not assembled by hand in a spreadsheet.
Get Your Cancellation Flow Set Up Correctly
If your agency is still handling cancellations through a chain of Telegram messages and manual bank transfers, you're spending 2–4 hours per cancellation on work that a well-configured CRM handles in under 10 minutes — most of it automatically. More importantly, you're creating disputes, errors, and reputational risk that no amount of careful manual work can fully prevent.
Setting up an automated cancellation and refund workflow requires three things: a clear written policy, a CRM configured to apply it consistently, and Click or Payme merchant accounts so refunds can be processed digitally. If you need help configuring any part of this for your agency, book a free consultation. We've implemented this workflow for agencies across Uzbekistan and can typically have it running within a week.
Как обрабатывать отмены и возвраты без ручной работы
Клиент отменяет тур за три дня до вылета. Что дальше? В большинстве агентств ответ предполагает цепочку ручных действий: кто-то уведомляет бухгалтера, бухгалтер рассчитывает сумму возврата, агент пишет клиенту, директор утверждает возврат, и в итоге кто-то заходит в интернет-банк и делает перевод. Клиент ждёт два-четыре дня — иногда дольше — и гадает, придут ли деньги вообще. К тому моменту, когда они всё-таки поступают, он уже рассказал двум друзьям, как сложно иметь дело с вашим агентством.
Отмены в туризме неизбежны. Рейсы отменяют. Визы не выдают. Случаются семейные обстоятельства. Важно не то, что бронирование отменяется, — важно то, насколько быстро и чисто вы это обрабатываете. В этой статье разобраны все компоненты современного автоматизированного процесса отмены и возврата: что нужно определить заранее, как настроить поток в CRM, как работают цифровые возвраты через Click и Payme и почему каждая отмена должна быть зафиксирована.
«Отменённое бронирование — это не конец отношений. Конец отношений — это медленный и запутанный процесс возврата.»
Почему ручная обработка отмен не работает
Проблема ручного процесса отмены не в том, что люди небрежны, — а в том, что процесс целиком зависит от того, помнят ли люди, правильно ли общаются и верно ли считают, без какой-либо системы для контроля ошибок или принудительного соблюдения шагов. Что обычно идёт не так:
- Ошибки в расчётах. Разные агенты применяют разные процентные ставки отмены. Нет единого источника правды по политике.
- Задержки из-за цепочки согласований. Бухгалтеру нужна виза директора. Директор на совещании. Клиент ждёт и звонит снова.
- Нет истории операций. Когда клиент оспаривает сумму возврата через месяц, никто не может найти запись об отмене или данные о том, кто её утвердил.
- Статус бронирования не обновлён. Место или номер остаются отмеченными как занятые в системе, блокируя новые продажи, пока кто-то не заметит и не исправит это вручную.
- Клиент не получает информацию. Без автоматического уведомления клиент не знает, принята ли его отмена и когда ждать возврата.
Каждый из этих сбоев предсказуем и предотвратим. Решение — не нанять более аккуратных сотрудников, а заменить ручной процесс структурированным автоматизированным рабочим потоком.
Определите политику отмены до всего остального
Автоматизация работает последовательно только при наличии чёткой политики для автоматизации. Прежде чем трогать настройки CRM, нужна письменная политика отмены, которая точно определяет, какой процент возвращается на каждом этапе. Типичная структура для турагентств в Узбекистане:
| Срок отмены | Сумма возврата | Примечания |
|---|---|---|
| 30+ дней до вылета | 100% возврат | За вычетом комиссии за обработку (если предусмотрена) |
| 15–29 дней до вылета | 75% возврат | Удерживается 25% штраф за отмену |
| 7–14 дней до вылета | 50% возврат | Депозит, как правило, невозвратный |
| 3–6 дней до вылета | 25% возврат | Только часть сверх невозвратных расходов |
| 0–2 дня до вылета | Без возврата | Применяется полный штраф за отмену |
Эта политика должна быть прописана в документах подтверждения бронирования, на странице подтверждения и в идеале — как чекбокс, который клиент подтверждает до оплаты. Когда это сделано, расчёт возврата становится формулой — а не оценочным суждением — и CRM может применять её автоматически, опираясь на дату вылета из карточки бронирования.
Автоматизация процесса отмены в CRM
После того как политика определена, CRM может обрабатывать всю операционную последовательность без вмешательства агента на каждом шаге. Вот как выглядит автоматизированный поток:
Клиент или агент инициирует отмену
Клиент отправляет запрос на отмену через форму на странице подтверждения бронирования, либо агент переводит бронирование в статус «Запрос на отмену» в CRM. Оба пути запускают один и тот же рабочий поток.
CRM автоматически рассчитывает сумму возврата
Система читает дату вылета из карточки бронирования, вычисляет количество оставшихся дней, применяет соответствующую ступень политики и показывает агенту сумму возврата для подтверждения — никакой ручной арифметики.
Статус бронирования меняется на «Отменено»
После подтверждения карточка бронирования переходит в статус «Отменено». Место или номер немедленно освобождается в системе доступности. История бронирования сохраняется с временной меткой и именем агента, обработавшего отмену.
Клиент получает автоматическое уведомление об отмене
Сразу отправляется шаблонное сообщение через Telegram или email: «Ваше бронирование [номер] отменено. Возврат в размере [сумма] будет выполнен на ваш счёт Click/Payme в течение 1–3 рабочих дней». Клиент знает сразу — без необходимости звонить.
Создаётся и назначается задача на возврат
В очереди задач бухгалтера в CRM появляется задача на возврат, уже заполненная: номер бронирования, имя клиента, способ оплаты, ID исходной транзакции и рассчитанная сумма возврата. Один клик — и можно открыть панель Click или Payme для обработки.
Обработка возвратов через Click и Payme
Если исходный платёж поступил через ваш мерчант-аккаунт Click или Payme — а так и должно быть, именно для таких случаев, — возврат прост. Не нужно инициировать банковский перевод, повторно запрашивать номер карты клиента или просить его предоставить дополнительную информацию.
Как это работает цифровым способом: Оба провайдера позволяют мерчантам инициировать возврат прямо из панели управления или через API, ссылаясь на ID исходной транзакции. Средства возвращаются на тот же счёт или карту, с которой клиент производил оплату. Как правило, деньги поступают в течение одного-трёх рабочих дней — в зависимости от провайдера и банка клиента.
Через панель мерчанта (без API): Войдите в Click Business или Payme Business, найдите транзакцию по номеру ссылки или дате, выберите «Возврат», введите сумму и подтвердите. Весь процесс занимает менее двух минут на транзакцию.
Через API (автоматически): Для агентств, обрабатывающих более 15–20 отмен в месяц, CRM может вызывать API Click или Payme напрямую, когда бухгалтер нажимает «Обработать возврат» в очереди задач. Никакого входа через браузер — возврат инициируется программно, а статус транзакции автоматически записывается в карточку бронирования.
Ключевой момент: если исходный платёж был получен как перевод на личную карту, ничего из этого невозможно. У агентства нет формального механизма возврата — только ручной банковский перевод без связи с исходным платежом, без автоматической записи и без защиты при споре. Это самый весомый практический аргумент в пользу перевода всего сбора платежей через мерчант-аккаунты.
Частичный возврат: депозит удержан, остаток возвращён
Многие агентства берут невозвратный депозит при бронировании — как правило, 20–30% от стоимости тура, — а остаток — ближе к вылету или при полной оплате. Когда отмена происходит после уплаты депозита, но до балансового платежа, нужно вернуть только остаток, удержав депозит.
На практике это выглядит так: если клиент заплатил 30%-й депозит — 3 000 000 сум, — а затем внёс 70% баланса — 7 000 000 сум, — и после этого отменяет бронирование в рамках 50%-го тира возврата: итоговая сумма оплаты — 10 000 000 сум, 50% возврата — 5 000 000 сум, из них 3 000 000 сум уже удержаны в виде невозвратного депозита, то фактически клиенту возвращается 2 000 000 сум.
CRM должна хранить каждую платёжную транзакцию отдельно — депозит, баланс, — привязанными к бронированию. При обработке отмены система ссылается на все связанные транзакции и рассчитывает чистую сумму возврата по всем платежам. Оба платежа могут быть частично возвращены через Click или Payme по соответствующим ID исходных транзакций. Клиент получает одно понятное сообщение: что было оплачено, что удержано и что будет возвращено — без возможности спорить об арифметике.
Расчёт частичного возврата по памяти вручную — именно так начинаются споры. Расчёт системой на основе сохранённых записей о транзакциях, письменно переданный клиенту, — именно так споры заканчиваются, не успев начаться.
Журнал и аудиторский след: каждая отмена должна быть зафиксирована
Каждая отмена, прошедшая через вашу систему, должна создавать неизменяемую запись в журнале. Это не бюрократия — это защита агентства в трёх вполне реальных ситуациях:
Минимальный набор полей каждой записи журнала отмен: номер бронирования, имя клиента, исходная сумма бронирования, дата отмены, дата вылета, дней до вылета на момент отмены, применённый тир политики, рассчитанная сумма возврата, утверждённая сумма возврата, способ оплаты, ID исходной(-ых) транзакции(-й), ID транзакции(-й) возврата и агент, обработавший отмену. Всё это должно генерироваться CRM автоматически — а не собираться вручную в таблице.
Настройте процесс отмены правильно
Если ваше агентство по-прежнему обрабатывает отмены через цепочки сообщений в Telegram и ручные банковские переводы, вы тратите 2–4 часа на каждую отмену на работу, которую правильно настроенная CRM выполняет менее чем за 10 минут, — и большую часть автоматически. Что важнее, вы создаёте споры, ошибки и репутационные риски, которые никакая аккуратная ручная работа не устранит полностью.
Для настройки автоматизированного процесса отмены и возврата нужны три вещи: чёткая письменная политика, CRM, настроенная для её последовательного применения, и мерчант-аккаунты Click или Payme для цифровой обработки возвратов. Если вам нужна помощь в настройке любой части для вашего агентства, запишитесь на бесплатную консультацию. Мы внедрили этот процесс для агентств по всему Узбекистану и, как правило, запускаем его в течение недели.
Bekor qilish va qaytarishlarni qoʻlda ish qilmasdan qanday boshqarish mumkin
Mijoz jo'nashdan uch kun oldin turni bekor qiladi. Keyin nima? Ko'pchilik agentliklarda bu qo'lda bajariladigan qadamlar zanjirini anglatadi: kimdir buxgalterga xabar beradi, buxgalter to'lanadigan summani hisoblaydi, agent mijozga yozadi, direktor qaytarishni tasdiqlaydi va oxir-oqibat kimdir internet-bankka kirib o'tkazma qiladi. Mijoz ikki-to'rt kun — ba'zan undan ham ko'p — kutadi va pul aslida kelishini hayron bo'lib o'ylaydi. Kelgan vaqtga kelib u allaqachon ikki do'stiga agentligingiz bilan muomala qilish qanchalik qiyin ekanligini aytib bo'lgan bo'ladi.
Turizm sohasida bekor qilishlar muqarrar. Reyslar bekor qilinadi. Vizalar rad etiladi. Oilaviy favqulodda hollar yuz beradi. Agentligingiz obro'siga bekor qilish zarar yetkazadimi yoki yo'qmi — bu bekor qilishning o'zi bilan emas, balki qanchalik tez va tartibli hal qilishingiz bilan belgilanadi. Ushbu maqolada zamonaviy avtomatlashtirilgan bekor qilish va qaytarish jarayonining barcha tarkibiy qismlari ko'rib chiqiladi: oldindan nima belgilash kerak, CRM da oqimni qanday sozlash kerak, Click va Payme orqali raqamli qaytarishlar qanday ishlaydi va nima uchun har bir bekor qilish qayd etilgan bo'lishi kerak.
«Bekor qilingan bron munosabatlarning oxiri emas. Munosabatlarning oxiri — sekin va chalkash qaytarish jarayonidir.»
Nima uchun bekor qilishni qo'lda boshqarish muvaffaqiyatsizlikka olib keladi
Qo'lda bekor qilish jarayonidagi muammo odamlarning ehtiyotsizligi emas — jarayon butunlay odamlar eslab qolishiga, to'g'ri muloqot qilishiga va to'g'ri hisoblashiga bog'liq, xatolarni aniqlash yoki qadamlarni majburlash uchun hech qanday tizim yo'q. Odatda nima noto'g'ri ketadi:
- Hisoblash xatolari. Turli agentlar turli bekor qilish foizlarini qo'llaydi. Siyosat bo'yicha yagona haqiqat manbai yo'q.
- Tasdiqlash zanjirlari tufayli kechikishlar. Buxgalterga direktorning imzosi kerak. Direktor yig'ilishda. Mijoz kutadi va yana qo'ng'iroq qiladi.
- Audit izi yo'q. Bir oy o'tib mijoz qaytarish summasini bahslashtirganda, hech kim asl bekor qilish yozuvini yoki kim tasdiqlagnini topa olmaydi.
- Bron holati yangilanmagan. O'rin yoki xona kimdir payqab qo'lda tuzatmaguncha tizimda band deb belgilanib qoladi, yangi sotuvlarni bloklaydi.
- Mijoz xabarsiz qoladi. Avtomatik bildirishnoma bo'lmagani uchun mijoz bekor qilish qabul qilinganmi va qaytarishni qachon kutish kerakligini bilmaydi.
Bu muvaffaqiyatsizliklarning har biri bashorat qilinadigan va oldini olish mumkin. Yechim — yanada ehtiyotkor odamlar yollash emas — qo'lda bajariladigan jarayonni tuzilgan, avtomatlashtirilgan ish oqimi bilan almashtirish.
Bekor qilish siyosatini boshqa hamma narsadan oldin belgilang
Avtomatlashtirish faqat avtomatlashtirish uchun aniq siyosat mavjud bo'lganda izchil ishlaydi. CRM sozlamalariga tegmasdan oldin, har bir bosqichda qancha foiz qaytarilishini aniq belgilovchi yozma bekor qilish siyosati kerak. O'zbekistondagi sayyohlik agentliklari uchun odatdagi tuzilma:
| Bekor qilish muddati | Qaytarish summasi | Izohlar |
|---|---|---|
| Jo'nashdan 30+ kun oldin | 100% qaytarish | Bron qayta ishlash to'lovini chegirib (agar mavjud bo'lsa) |
| Jo'nashdan 15–29 kun oldin | 75% qaytarish | 25% bekor qilish jarimasi ushlab qolinadi |
| Jo'nashdan 7–14 kun oldin | 50% qaytarish | Depozit odatda qaytarilmaydi |
| Jo'nashdan 3–6 kun oldin | 25% qaytarish | Faqat qaytarilmaydigan xarajatlardan yuqori qism |
| Jo'nashdan 0–2 kun oldin | Qaytarish yo'q | To'liq bekor qilish jarimasi qo'llaniladi |
Bu siyosat bron tasdiqlash hujjatlarida, bron tasdiqlash sahifasida va ideali — mijoz to'lovdan oldin tasdiqlaydigan belgi katakchasi sifatida ko'rsatilishi kerak. Bu amalga oshirilganda, qaytarish hisobi baholovchi qaror emas, formulaga aylanadi — va CRM bron yozuvida saqlangan jo'nab ketish sanasiga asoslanib uni avtomatik ravishda qo'llashi mumkin.
CRM da bekor qilish oqimini avtomatlashtirish
Siyosat belgilangandan so'ng, CRM har bir qadamda agent aralashuvisiz butun operatsion ketma-ketlikni boshqara oladi. Avtomatlashtirilgan oqim qanday ko'rinadi:
Mijoz yoki agent bekor qilishni boshlaydi
Mijoz bron tasdiqlash sahifasidagi forma orqali bekor qilish so'rovi yuboradi yoki agent CRM da bronni «Bekor qilish so'rovi» holatiga o'tkazadi. Ikkala yo'l ham bir xil ish oqimini ishga tushiradi.
CRM qaytarish summasini avtomatik hisoblaydi
Tizim bron yozuvidan jo'nab ketish sanasini o'qiydi, qolgan kunlar sonini hisoblaydi, mos siyosat bosqichini qo'llaydi va agentga tasdiqlash uchun qaytarish summasini ko'rsatadi — qo'lda arifmetika shart emas.
Bron holati «Bekor qilindi» ga o'zgaradi
Tasdiqlanganidan so'ng bron kartochkasi «Bekor qilindi» holatiga o'tadi. O'rin yoki xona mavjudlik tizimida darhol bo'shatiladi. Bron tarixi vaqt belgisi va uni amalga oshirgan agent nomi bilan saqlanadi.
Mijoz avtomatik bekor qilish bildirishnomasini oladi
Telegram yoki elektron pochta orqali darhol shablonli xabar yuboriladi: «[Raqam] broningiz bekor qilindi. [Summa] miqdoridagi qaytarish 1–3 ish kuni ichida Click/Payme hisobingizga o'tkaziladi». Mijoz qo'ng'iroq qilmasdan darhol biladi.
Qaytarish vazifasi yaratiladi va tayinlanadi
CRM dagi buxgalter vazifa navbatida qaytarish vazifasi paydo bo'ladi, allaqachon to'ldirilgan: bron raqami, mijoz ismi, to'lov usuli, dastlabki tranzaksiya identifikatori va hisoblangan qaytarish summasi. Click yoki Payme merchant paneliga kirib qayta ishlash uchun bir marta bosish kifoya.
Click va Payme orqali qaytarishni qayta ishlash
Agar dastlabki to'lov Click yoki Payme merchant hisobingiz orqali amalga oshirilgan bo'lsa — va aynan shu sabab uchun shunday bo'lishi kerak — qaytarish oddiy. Bank o'tkazmasi boshlash, mijozning karta raqamini qayta so'rash yoki undan qo'shimcha ma'lumot talab qilish shart emas.
Raqamli yo'l bilan qanday ishlaydi: Click ham, Payme ham merchantlarga dastlabki tranzaksiya identifikatoriga murojaat qilib, merchant paneli yoki API orqali to'g'ridan-to'g'ri qaytarishni boshlash imkonini beradi. Qaytarish mijoz dastlabki to'lovni amalga oshirgan hisobraqam yoki kartaga o'tkaziladi. Odatda provayder va mijozning bankiga qarab mablag'lar bir-uch ish kuni ichida tushadi.
Merchant paneli orqali (API siz): Click Business yoki Payme Business ga kiring, tranzaksiyani havola raqami yoki sana bo'yicha toping, «Qaytarish» ni tanlang, summani kiriting va tasdiqlang. Hammasi shu. Butun jarayon tranzaksiya boshiga ikki daqiqadan kam vaqt oladi.
API orqali (avtomatik): Oyiga 15–20 dan ortiq bekor qilishni qayta ishlaydigan agentliklar uchun, buxgalter vazifa navbatida «Qaytarishni qayta ishlash» tugmasini bosganda CRM to'g'ridan-to'g'ri Click yoki Payme API ga murojaat qilishi mumkin. Brauzerga kirish shart emas — qaytarish dasturiy ravishda boshlanadi va tranzaksiya holati avtomatik ravishda bron yozuviga yozib qo'yiladi.
Asosiy nuqta: agar dastlabki to'lov shaxsiy karta o'tkazmasi sifatida yig'ilgan bo'lsa, bularning hech biri mumkin emas. Agentlikning rasmiy qaytarish mexanizmi yo'q — faqat dastlabki to'lov bilan bog'liqligi bo'lmagan, avtomatik yozuvsiz va nizodagi himoyasiz qo'lda bank o'tkazmasi. Bu barcha to'lov yig'imini merchant hisoblar orqali o'tkazish uchun eng kuchli amaliy sababdir.
Qisman qaytarishni boshqarish: depozit ushlab qolinadi, qoldiq qaytariladi
Ko'p agentliklar bron qilishda qaytarilmaydigan depozit oladilar — odatda tur narxining 20–30% i — va qolgan qismi jo'nashga yaqin yoki to'liq to'lov amalga oshirilganda. Depozit to'langandan keyin, lekin balans to'lovdan oldin bekor qilish yuz berganda, faqat balans qismini qaytarib, depozitni ushlab qolish kerak.
Amalda bu shunday ko'rinadi: agar mijoz 3 000 000 so'm 30% depozit to'lagan bo'lsa va keyin 7 000 000 so'm 70% balans to'lagan bo'lsa, so'ngra 50% qaytarish bosqichida bekor qilsa: jami to'langan — 10 000 000 so'm, 50% qaytarish — 5 000 000 so'm, bundan 3 000 000 so'm qaytarilmaydigan depozit sifatida allaqachon ushlab qolingan, demak mijozga haqiqatda qaytariladigan summa — 2 000 000 so'm.
CRM har bir to'lov tranzaksiyasini alohida saqlashi kerak — depozit to'lovi, balans to'lovi — bronga bog'liq holda. Bekor qilish qayta ishlanayotganda tizim barcha bog'liq tranzaksiyalarga murojaat qiladi va barcha to'lovlar bo'yicha sof qaytarish summasini hisoblaydi. Ikkala tranzaksiya ham tegishli dastlabki tranzaksiya identifikatorlari bo'yicha Click yoki Payme orqali qisman qaytarilishi mumkin. Mijoz bitta aniq xabar oladi: nima to'langan, nima ushlab qolingan va nima qaytariladi — arifmetika bo'yicha bahslashish imkoni yo'q.
Xotiradan qo'lda hisoblangan qisman qaytarish — nizolar qanday boshlanadi. Saqlangan tranzaksiya yozuvlaridan tizim tomonidan hisoblab, yozma ravishda mijozga ko'rsatilgan qisman qaytarish — nizolar boshlanishidan oldin qanday tugaydi.
Jurnalga yozish va audit izi: har bir bekor qilish qayd etilishi kerak
Tizimingiz orqali o'tgan har bir bekor qilish o'zgartirib bo'lmaydigan jurnal yozuvini yaratishi kerak. Bu byurokratiya emas — bu uchta juda real vaziyatda agentligingizni himoya qiladi:
Har bir bekor qilish jurnal yozuvida bo'lishi kerak bo'lgan minimal maydonlar: bron raqami, mijoz ismi, dastlabki bron summasi, bekor qilish sanasi, jo'nab ketish sanasi, bekor qilish vaqtida jo'nab ketishgacha qolgan kunlar, qo'llanilgan siyosat bosqichi, hisoblangan qaytarish summasi, tasdiqlangan qaytarish summasi, to'lov usuli, dastlabki tranzaksiya identifikatori(-lari), qaytarish tranzaksiya identifikatori(-lari) va bekor qilishni qayta ishlagan agent. Bularning barchasi CRM tomonidan avtomatik ravishda yaratilishi kerak — elektron jadvalda qo'lda yig'ilmagan holda.
Bekor qilish oqimingizni to'g'ri sozlang
Agar agentligingiz hali ham Telegram xabarlari va qo'lda bank o'tkazmalari orqali bekor qilishlarni qayta ishlayotgan bo'lsa, siz har bir bekor qilishga to'g'ri sozlangan CRM 10 daqiqadan kamroq vaqtda — va aksariyat qismi avtomatik ravishda — bajariladigan ish uchun 2–4 soat sarflamoqdasiz. Eng muhimi, siz hech qanday ehtiyotkor qo'l ishi to'liq oldini ololmaydigan nizolar, xatolar va obro' xatarlarini yaratmoqdasiz.
Avtomatlashtirilgan bekor qilish va qaytarish ish oqimini sozlash uchun uchta narsa kerak: aniq yozma siyosat, uni izchil qo'llash uchun sozlangan CRM va raqamli qaytarishlarni qayta ishlash uchun Click yoki Payme merchant hisoblar. Agentligingiz uchun biron-bir qismni sozlashda yordam kerak bo'lsa, bepul konsultatsiyaga yozing. Biz bu ish oqimini O'zbekiston bo'ylab agentliklar uchun tatbiq etganmiz va odatda bir hafta ichida ishga tushiramiz.
