Дашборд для турагентства 2026: заявки, брони, комиссии, отмены и пакеты без самообмана

Дашборд для турагентства нужен не для красивой диаграммы "продажи по странам", а для ежедневного контроля денег и рисков: какие заявки зависли без ответа, какие брони еще не оплачены, где комиссия ожидается, но может быть отозвана после отмены, какой менеджер продает прибыльные пакеты, а какой просто набирает оборот с низкой маржой.

В туризме особенно опасна простая метрика "выручка". Одна строка может быть лидом, заявкой, предварительной бронью, подтвержденной бронью, счетом, частичной оплатой, отменой, возвратом, агентской комиссией или пакетным туром с несколькими услугами. SimpleDashboard помогает быстро собрать первый управленческий экран из U-ON.Travel, CRM, Excel, TourCMS, GDS/OTA-выгрузок или бухгалтерии, но правила статусов и исключений должны быть подписаны прямо в дашборде.

Эта статья для владельца турагентства, руководителя отдела продаж, туроператора, DMC, travel advisor, host agency или менеджера, который хочет видеть в одном месте заявки, брони, пакеты, оплаты, комиссии, отмены, источники лидов и качество данных.

В нашем практическом разборе таблицы турагентства дашборд сначала показывал "хороший месяц", но после сверки выяснилось: часть сумм была gross price без комиссии, часть броней имела статус provisional, несколько счетов были canceled, а комиссии считались по booking date, хотя выплата зависела от travel date и supplier payment rules. Поэтому первый шаг - не графики, а словарь статусов и контрольные строки.

Главное

• U-ON.Travel API разделяет статусы лидов, статусы заявок, статусы бронирования, счета, оплаты, отмены, услуги, туристов и комиссии по платежам. Для турагентства это означает: один общий "статус сделки" почти всегда слишком грубый.
• Travelgate Dashboard для travel distribution показывает real-time bookings, total searches, bookings OK, cancellations OK, look-to-book ratio, GMV/TTV и top connections. Эти метрики полезны для OTA/GDS/API-каналов, но их нельзя бездумно переносить на ручные продажи туров.
• Travelport Universal API предупреждает: отмена может выполняться на уровне Universal Record или PNR, а для отдельных типов контента действуют исключения. Поэтому dashboard должен показывать не только "cancelled", но и источник, уровень отмены, refund/exchange status и ручные действия.
• TourCMS booking API возвращает статус booking, cancel_reason, payment_status, sales_revenue, commission, agent type, components and payments. Для туроператора и агентства это сигнал хранить пакет не одной суммой, а набором компонентов: перелет, отель, трансфер, экскурсия, страховка, сервисный сбор.
• Tourplan Package Financial Summary разделяет финансовую сторону групповых/пакетных туров: выручка может лежать на индивидуальных FIT bookings, а расходы - на групповых компонентах. Поэтому прибыль пакета нельзя оценивать только по gross sales.
• Форумы и Reddit ниже использованы только как signal-only: агенты чаще всего жалуются на chasing commissions, поздние выплаты, clawback после отмен, путаницу host agency/supplier, ошибки booking number и ручные таблицы. Это не источник норм или процентов, а список рисков для проверки в ваших данных.

SimpleDashboard стоит 5 000 ₽/мес и подходит как первый проверяемый слой: загрузить выгрузку, увидеть заявки, оплаты, отмены, комиссии и ошибки данных, а затем решить, какие интеграции подключать постоянно.

KPI/risk table для турагентства

Для первого экрана турагентства обычно достаточно 8-12 блоков: новые заявки, просроченные ответы, воронка lead -> quote -> booking -> paid, оборот и net revenue, комиссии expected/received/overdue, отмены, refunds, package margin, продажи по направлениям, manager load, departure risk и data quality.

Какие данные нужны для пилота

Для CSV/XLSX-пилота хватит 30-90 дней истории и будущих выездов на 30-60 дней:

• leads: lead_id, created_at, source, campaign, client segment, manager_id, lead_status, reason_deny;
• quotes: quote_id, lead_id, sent_at, direction, travel dates, travelers count, budget, quote_status;
• bookings: booking_id, request_id, supplier, tour_operator, GDS/OTA/source, booking_status, confirmation_number, created_at, departure_date, return_date;
• package components: flight, hotel, transfer, tour, cruise, insurance, visa, activity, service fee, component supplier, component status;
• payments: invoice_id, amount, currency, paid_at, hold/refund/cancel flags, payment method, acquiring fee;
• commissions: expected commission, received commission, commission currency, supplier rule, paid date, overdue flag, clawback/refund flag;
• cancellations/refunds: cancel_reason, cancelled_at, penalty, refund_requested_at, refund_received_at, refund_paid_to_client_at;
• managers: manager_id, office, role, active queue, overdue tasks, closed bookings;
• data quality: source_system, export_time, duplicate booking, missing status, missing supplier, stale update.

Если в первой выгрузке нет комиссий или возвратов, это не блокер. Но такие показатели нужно пометить как неполные, ожидаемые или требуют ручной сверки, а не выдавать за финальную прибыль.

Что говорят официальные travel/booking sources

U-ON.Travel: статусы, счета, услуги и комиссии надо связывать

U-ON.Travel API показывает, что туристическая CRM хранит отдельные сущности: лиды, заявки, статусы обращений, статусы заявок, статусы бронирования, счета, оплаты, услуги, туристов, файлы и комиссии по платежам. В счетах есть признаки оплаты, холда, отмены и дата отмены; в заявках есть услуги, туристы, платежи и commission collection.

Практический вывод: дашборд турагентства должен связывать lead -> request -> booking -> services -> payments -> commission, а не строить продажи по одному полю price. Иначе менеджер с большим gross оборотом будет выглядеть лучше менеджера с меньшим оборотом, но более высокой комиссией и меньшими отменами.

Travelgate: для API/OTA важны bookings OK, cancellations OK и look-to-book

Travelgate Dashboard Reports описывает real-time bookings, total searches, total bookings OK, total cancellations OK, look-to-book ratio, GMV/TTV и top connections. Это полезный словарь для travel distribution: если агентство или туроператор получает брони через API/OTA/GDS-подобные каналы, нужно видеть не только продажи, но и спрос, отмены, конверсию поисков в брони и top connections.

Практический caveat: look-to-book ratio полезен для API/OTA-трафика, но почти бесполезен для ручных заявок из Telegram или WhatsApp. Для ручных продаж лучше считать response time, quote sent, follow-up overdue, booking confirmation и payment status.

Travelport: cancellation не всегда одна кнопка

Travelport Universal API отдельно указывает, что отмена может выполняться на уровне Universal Record или PNR, а отдельные сегменты, ACH/Rail и supplier-specific cases могут требовать exchange/refund или другой процедуры. В NDC/GDS-операциях похожая проблема: статус в одном интерфейсе не всегда означает, что поставщик, билет, PNR и финансовая часть уже синхронизированы.

Практический вывод: в дашборде нужно отделять booking cancelled, ticket voided, refund quoted, refund processed, supplier refund received, client refund paid, commission clawback. Одна колонка cancelled = yes не закрывает управленческий риск.

TourCMS: booking status и cancel_reason надо проверять вместе

TourCMS booking list API возвращает booking status, cancel_reason, payment_status, sales_revenue, commission, agent type, payments and components. В документации отдельно указано: даже если booking имеет provisional status, наличие cancel_reason может означать, что бронь фактически отменена; чтобы убедиться, что бронь не отменена, надо проверять cancel_reason.

Для дашборда это важная защита от красивой ошибки. Фильтр status in confirmed/provisional недостаточен, если отмена хранится отдельным полем. В первом прототипе обязательно нужен блок bookings with inconsistent status: confirmed + cancel_reason, paid + cancelled, commission expected + refunded, departure soon + unpaid.

Tourplan: пакетная прибыль живет по компонентам

Tourplan Package Financial Summary описывает пакетные/групповые туры так: revenue может относиться к индивидуальным FIT bookings, а expenses - к компонентам группового тура; отчет динамически меняется после добавления FIT bookings, debtor invoices, receipts, creditor invoices и payments. Там же указано, что это financial report, not operational information.

Практический вывод: для пакетного тура один gross total не объясняет прибыль. Нужны компоненты: перелет, отель, трансфер, экскурсии, страховка, сервисный сбор, supplier cost, invoice status и payment status. Отдельно должен быть operational layer: документы, визы, ваучеры, билеты, departure checklist.

Tres Technologies: комиссии зависят от даты брони, даты поездки и даты оплаты

Tres My Sales & Agency Commissions Dashboard показывает commissions by booking date, travel date and paid date, projected commissions based on supplier payment rules, top clients and top suppliers by yield. Yield считается как commission divided by total fare.

Практический вывод: для турагентства опасно считать комиссию только в момент бронирования. На дашборде нужны как минимум три даты: booking date, travel date/departure date и commission paid date. Иначе агентство видит ожидаемую прибыль, но не видит просрочку выплаты или риск возврата комиссии после отмены.

132-ФЗ и 152-ФЗ: юридический контекст нельзя прятать в график

Федеральный закон N 132-ФЗ регулирует туристскую деятельность в РФ, включая особенности формирования, продвижения и реализации туристского продукта, реестры туроператоров/турагентов и требования к договору. Для дашборда это не "юридическая справка", а практический caveat: туристский продукт, договор, туроператор, турагент, финансовое обеспечение и ответственность сторон нельзя подменять внутренним статусом CRM.

Федеральный закон N 152-ФЗ о персональных данных важен потому, что в travel-данных часто есть ФИО, паспорта, даты рождения, телефоны, email, данные детей, визовые документы, страховки, платежные детали и special requests. Для управленческого дашборда обычно достаточно booking_id, source, dates, direction, status, amounts and flags; персональные данные лучше удалять или заменять внутренними идентификаторами.

Forum/community signals: что проверять руками

Форумы не являются источником норм, процентов или юридических выводов. Но они хорошо показывают, где туристические операции ломаются в реальной жизни.

В r/travelagents регулярно обсуждают chasing commissions, late commissions, booking numbers, host agency payout rules, supplier payment timing и ситуации, когда комиссия может быть clawed back после отмены. Это signal добавить в dashboard не только expected commission, но и received, overdue, supplier payment rule, travel completed, refund/clawback risk.

В обсуждениях commission tracking агенты часто описывают ручные таблицы с customer name, travel dates, commission due date, supplier и booking number. Это не доказывает, что все агентства работают одинаково; это говорит, что минимальный финансовый экран должен начинаться с reconciliation queue: "какие комиссии нужно проверить сегодня".

В travel agent communities также всплывают боли по last-minute bookings, supplier not preferred by host agency, non-commissionable air, group booking issues, cancellations, schedule changes and Agent Debit Memo risks. Для дашборда это signal добавить разрезы: supplier type, commissionable/non-commissionable, group booking, departure soon, manual follow-up и exception owner.

Как собрать дашборд турагентства через SimpleDashboard

Шаг 1. Выгрузите данные и словарь статусов

Возьмите выгрузку из U-ON.Travel, CRM, Excel, бухгалтерии, TourCMS, GDS/OTA, системы туроператора или host agency portal. Отдельно приложите словарь: что означает new, qualified, quote sent, confirmed, paid, cancelled, refunded, on request, provisional, ticketed, documents ready, commission paid.

Если словаря нет, SimpleDashboard соберет черновую модель, но спорные статусы попадут в блок проверки. Это лучше, чем молча нарисовать воронку по названиям колонок.

Шаг 2. Отправьте файл в Telegram

Загрузите CSV/XLSX в @coderboxbot и напишите:

Собери дашборд турагентства: новые заявки, response time, lead-to-quote, quote-to-booking, confirmed bookings, paid bookings, gross booking value, net agency revenue, expected/received/overdue commissions, cancellations, refunds, package margin, manager load, departure risk и data quality errors.

AI предложит структуру графиков и найдет подозрительные поля, но финальные правила утверждает человек: какие статусы считаются продажей, какие оплаты входят в revenue, как учитывать refunds, где комиссия ожидаемая, а где уже полученная.

Шаг 3. Сверьте контрольные числа

Перед публикацией проверьте руками минимум:

1. Количество новых лидов за период.
2. Количество qualified leads.
3. Количество отправленных предложений.
4. Подтвержденные брони без отмен.
5. Оплаченные брони.
6. Gross booking value и net agency revenue.
7. Expected, received и overdue commissions.
8. Отмены по booking date и по departure date.
9. Refunds requested/received/paid.
10. 10-20 реальных booking_id от лида до комиссии.

Если контрольные строки не сходятся с CRM, порталом поставщика и бухгалтерией, сначала исправляется mapping. Дашборд с неверной базой будет быстрее принимать неверные решения.

Что показывать на первом экране

Source-backed caveats

1. Gross sales не равен доходу агентства. Для турагентства важнее net agency revenue, commission yield, received commission и overdue commission.
2. Confirmed booking не всегда финальная продажа. Проверяйте payment status, cancel_reason, ticketing/docs, refund status и departure date.
3. Комиссия зависит от правил поставщика. Tres показывает комиссии в разрезе booking date, travel date and paid date; supplier payment rules могут сдвигать доход на месяцы.
4. OTA/GDS cancellation может быть многоуровневой. Travelport описывает разные уровни cancellation; статус CRM должен сверяться с PNR/ticket/refund.
5. Look-to-book подходит не всем каналам. Travelgate metrics полезны для API/OTA distribution, но ручные Telegram/WhatsApp-заявки требуют другой воронки.
6. Пакетный тур нельзя считать одной строкой. TourCMS и Tourplan показывают components, payments, agent fields and package financial logic; margin надо считать по компонентам.
7. Форумы - это risk backlog, не доказательство. Reddit/travel agent communities помогают увидеть боли по commission tracking, cancellations and host agency rules, но числа и правила нужно проверять по официальным docs и вашим договорам.
8. AI не утверждает методологию. AI ускоряет группировку данных, но формулы, статусы, юридические caveats и контрольные booking_id утверждает владелец процесса.

Privacy и ограничения

Для пилота обычно не нужны паспортные данные, даты рождения детей, полные телефоны, email, номера карт, сканы документов, визовые анкеты, medical notes и свободные комментарии менеджеров. Достаточно client_id, booking_id, dates, direction, status, source, amount, commission, supplier and flags.

Если нужно анализировать повторные покупки, используйте внутренний client_id или hash. Если нужно сравнить менеджеров, не выводите персональные данные туристов на общий экран. Если KPI влияют на премии, штрафы или юридические решения, формулы и источники должны быть утверждены отдельно и храниться с audit trail.

Ограничения, которые стоит подписать на дашборде:

• дашборд не заменяет CRM, GDS, портал туроператора, бухгалтерию и договорную базу;
• expected commission не равна received commission;
• gross booking value не равен прибыли;
• provisional/on request booking не равна confirmed sale;
• cancellation date, booking date и travel date отвечают на разные вопросы;
• refunds и clawbacks могут закрываться позже отчетного периода;
• персональные данные туристов нужно минимизировать;
• forum/community signals используются только для поиска рисков, не для финансовых норм.

Когда Excel достаточно, а когда нужен дашборд

SimpleDashboard не пытается заменить отраслевые системы. Его роль - быстро собрать проверяемый управленческий слой поверх выгрузок: где спрос, где продажа, где деньги, где комиссия, где отмена и где данным нельзя доверять.

Часто задаваемые вопросы

Какие KPI обязательны для дашборда турагентства?

Минимум: новые заявки, first response time, lead-to-quote, quote-to-booking, confirmed bookings, paid bookings, gross booking value, net agency revenue, expected/received/overdue commissions, cancellation rate, refund exposure, package margin, manager load, source ROI and data quality errors.

Почему нельзя смотреть только выручку по турам?

Потому что gross price может включать деньги поставщика, налоги, перелет, отель, трансфер, сервисный сбор и платежи клиента, но не показывать агентскую комиссию, маржу, возвраты и риск clawback. Для управления нужен net agency revenue и commission status.

Как учитывать отмены?

Считайте отмены минимум в двух разрезах: по дате отмены и по дате выезда. Первый показывает текущую операционную нагрузку и refunds, второй показывает качество будущего прогноза и риск провала плановой прибыли.

Можно ли подключить U-ON.Travel, TourCMS, GDS или OTA автоматически?

Да, если источник отдает API, регулярный CSV/XLSX или отчет. Для первой версии часто быстрее начать с выгрузки и словаря статусов, а API подключить после сверки контрольных booking_id, комиссий и отмен.

Что делать с пакетными турами?

Разложить пакет на компоненты: flight, hotel, transfer, tour/activity, insurance, visa, service fee, supplier cost, payment and document status. Gross package price без компонентов не покажет реальную маржу и операционные риски.

Форумы можно использовать как источник для статьи?

Только как signal-only. Они помогают увидеть практические боли - late commissions, chasing payments, supplier rules, cancellations, booking number mistakes. Но формулы, юридические правила и финансовые выводы нужно брать из официальных docs, договоров и ваших данных.

AI сам поймет правильные статусы?

AI может предложить mapping и найти аномалии, но не должен сам решать, что считать продажей, отменой, комиссией или финальной прибылью. Эти правила утверждает владелец процесса, иначе dashboard будет выглядеть уверенно и ошибаться.

Что подготовить перед внедрением

• выгрузку лидов, заявок, броней, оплат и отмен за 30-90 дней;
• будущие выезды на 30-60 дней;
• словарь статусов CRM/туроператора/GDS/OTA;
• справочник менеджеров, поставщиков, туроператоров и направлений;
• данные по комиссиям: expected, received, paid date, supplier rule;
• refund/clawback fields и причины отмен;
• package components and supplier costs;
• источники лидов и рекламные расходы, если нужен ROI;
• 10-20 реальных booking_id для ручной сверки от лида до комиссии.

Стоимость SimpleDashboard - 5 000 ₽/мес. Напишите в Telegram: @coderboxbot - соберем первый дашборд турагентства по вашей выгрузке и отдельно покажем, какие KPI нельзя считать финальными без сверки с CRM, поставщиком и бухгалтерией.

Подробнее о возможностях SimpleDashboard

Смотрите также

• Дашборд для директора 2026: как видеть все показатели бизнеса на одном экране
• KPI дашборд 2026: как настроить мониторинг ключевых показателей
• CRM для малого бизнеса 2026: альтернатива без переплаты
• Аналитика продаж 2026: как считать KPI и строить отчеты за 5 минут
• Дашборд из CSV и Excel 2026: загрузи таблицу - получи аналитику за 5 минут
• Финансовый дашборд 2026: как отслеживать выручку, расходы и прибыль

Источники

• U-ON.Travel API documentation: https://api.u-on.travel/doc
• Travelgate Dashboard Reports: https://docs.travelgate.com/kb/platform/app-features/dashboard/dashboard-reports/
• Travelport Universal API: Canceling Bookings: https://support.travelport.com/webhelp/uapi/Content/Booking/Cancel/Canceling_Bookings.htm
• TourCMS API: List bookings: https://www.tourcms.com/support/api/mp/booking_list.php
• Tourplan Package Financial Summary Report: https://usermanuals.tourplan.com/v2/Content/NX%20PCMs/PCM%20Packages/D%20-%20Setting-up%20Component%20Tours/1.9%20-%20Component%20Package%20Tours%20-%20Tour%20Operations%20-%20Reporting.htm
• Tres Technologies My Sales & Agency Commissions Dashboard: https://trestechnologieshelp.zendesk.com/hc/en-us/articles/29618679555091-Tres-My-Sales-Agency-Commissions-Dashboard
• Федеральный закон N 132-ФЗ "Об основах туристской деятельности в Российской Федерации": https://www.consultant.ru/document/cons_doc_LAW_12462/
• Федеральный закон N 152-ФЗ "О персональных данных": https://pravo.gov.ru/
• Reddit r/travelagents community signals: commission tracking, late commissions, host agency payout, booking cancellations and supplier rules; использовано только как signal-only, не как источник фактов или нормативов.

Статья по продукту simple_dashboard подготовлена с использованием AI и ручной редакторской проверкой: Александр Руин, основатель habab.ru. Обновлено: 2026-05-05.