IOSOR

IOSOR База знаний

Finance и product делят один export

Дашборды product и close finance должны читать один и тот же DLR export. Вторая таблица с «мягкими» статусами — это будущий провал сверки.

Finance и product оба нужны messaging-правда на month-end. Типичный провал — два файла: дашборд product со «success» и лист finance с delivered receipts. Когда они расходятся, кошелёк выглядит сломанным, даже если prepaid debit были верны.

IOSOR ждёт одну схему export для обоих мест. Одни статусы DLR, одни границы периода, одни ключи коридоров. Product может строить графики; finance — сводные; никто не изобретает свой словарь статусов.

Один export, два места, одни колонки DLR

Публикуйте один report export, который тянут и product, и finance. Колонки называют delivered, failed, unknown, rejected и spend на общем языке статусов. Product добавляет графики; finance — invoice-заметки — они не переименовывают unknown в delivered ради мягкого слайда.

Зафиксируйте часы периода. Если product закрывает неделю в пятницу 23:59 UTC, а finance — календарный месяц, задокументируйте cut и выводите оба представления из одних и тех же строк export. Не давайте командам тянуть разные API-снимки «для удобства».

Общий язык статусов — контракт

Общий язык статусов для product и finance — контракт, из-за которого один export usable. Delivered значит receipt. Submitted — accept-for-send, не inbox. Unknown — всё ещё ждём. Если product пишет «OK», а finance — «DLR delivered», у вас уже две правды под одними заголовками CSV.

Обучите обе команды одному глоссарию до первого совместного close. Когда тикет говорит, что дашборд не сходится с invoice-неделей, сначала откройте export — не боковой лист. Operating guide по deliverability SMS остаётся рядом для ops-ремонта, но цифры, о которых спорят оба места, должны идти из общего файла.

Volume review читает тот же файл

Wallet volume review и spend governance сидят на том же export. Мягкий review при более высоком месячном spend всё равно использует delivered и debit-правду из общего пака — не marketing funnel count. Если governance просит «successful sends», переведите это в delivered receipts в export, никогда в submit totals.

Когда spend скачет, product и finance открывают одни строки: какие коридоры дали delivered, где выросла доля unknown, какие refund пришли. Отдельные воронки создают тихий drift governance.

Откажитесь от второй таблицы

Теневой лист, который «чистит» статусы для board — антипаттерн. Удалите его или пометьте unofficial. Если leadership нужен проще вид — график поверх канонического export, без ручного редактирования статусов. Партнёры на white-label поверхностях — то же правило: один контракт export, без частных aliases success.

Связанные пути

Начните с IOSOR

Настройте регулярный экспорт отчетов в консоли IOSOR с единым набором колонок DLR и расходов для финансов и продукта. Выгружайте сырые статусы без ручных интерпретаций, используя статус delivered только при наличии финального чека доставки, а unknown — для ожидающих подтверждения сообщений. Зафиксируйте закрытый период в консоли, чтобы исключить изменения задним числом в обеих командах.

Итог IOSOR

Этот материал доказал, что для продуктовой команды и финансового отдела необходим один канонический файл выгрузки отчетов. Использование единого языка статусов исключает споры о расходах и конверсии, так как статусы delivered, failed и unknown трактуются одинаково во всех отчетах.

Используйте единый автоматический экспорт IOSOR как единственный источник правды для сверки баланса и продуктовых дашбордов. Не создавайте теневых ручных таблиц и не переименовывайте статус unknown в delivered ради красивых графиков для руководства.

Был ли материал полезен?

Связанные гайды