Перейти к содержимому

Согласование запросов на возврат

Внутренний процесс для агентов поддержки, руководителей и финансового отдела, в котором каждый запрос клиента на возврат денег проходит от поступления до решения по одинаковым правилам. Он отвечает на вопросы: кто рассматривает запрос, нужно ли согласование и почему было принято решение.

Без него запросы приходят по почте, в чат и через менеджеров, а общей очереди нет. Агент собирает историю запроса по нескольким системам, сроки ведут в таблице, которая устаревает к моменту открытия, а сложные случаи ходят между агентом и руководителем, пока клиент не напишет снова. Одинаковые запросы получают разные решения, а отчёт по возвратам выходит раз в неделю.

Процесс особенно полезен компаниям с подписками и интернет-магазинам, где возвраты случаются каждый день и напрямую влияют на выручку. Первая версия — очередь, карточка и ручное согласование; автоматические правила и связь со спорными платежами добавляют, когда накоплена статистика решений и согласованы пороги с финансовым отделом.

  • Собирает запросы в одну очередь. Запросы из всех каналов получают единый статус, ответственного и срок решения.
  • Показывает всю историю на одной странице. Заказ или подписка, сумма, переписка, вложения и прошлые возвраты клиента видны в карточке запроса.
  • Направляет на согласование по порогу. Запросы выше суммы, заданной в правилах, или от клиентов с частыми возвратами автоматически уходят руководителю.
  • Фиксирует причину решения. Одобрение и отказ требуют выбранной причины из справочника и комментария.
  • Отслеживает последствия. Отказы, после которых клиент оспорил платёж в банке, отмечаются для разбора правил.
  • Ответственный — с первой минуты. Запрос автоматически назначают по каналу или продукту, иначе он лежит без движения. Эскалация без заметки о том, что уже проверено, запрещена.
  • Автоодобрение — только по явным правилам. Например, возврат до небольшой суммы для подтверждённого клиента без прошлых возвратов. Пороги хранят как настройки и пересматривают вместе с финансами, а каждое автоматическое решение журналируют.
  • Сам возврат делает платёжная система. Панель принимает решение и передаёт его в платёжного провайдера или биллинг через API, сохраняя ответ. Деньги не должны уходить по ручному действию вне процесса, а повторное нажатие не должно создавать второй возврат.
  • Причины отказа — справочник, а не свободный текст. Только так можно увидеть, где правила неясны или применяются по-разному.
  • Срок хранят в записи. Срок решения вычисляется при поступлении и не живёт в отдельной таблице. Приближение к сроку подсвечивает строку и уведомляет ответственного.
  • Help desk не заменяется. Переписка остаётся в Zendesk, Freshdesk или Intercom, панель читает запросы через API и возвращает туда статус. Если возвратов мало и хватает макроса в help desk плюс ручного шага в биллинге, отдельный процесс не окупится.
  • Доступ ограничивают на сервере. Агент видит свои запросы, руководитель — все открытые, финансы — всё с выгрузкой. Платёжные данные клиента показывают частично.

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

Создай модели и миграции для запросов на возврат: RefundRequest (источник,
внешний id обращения, клиент, заказ или подписка, сумма, валюта, статус,
ответственный, срок решения, причина решения, комментарий, внешний id
возврата в платёжной системе), RefundReason (код, название, тип: одобрение
или отказ), RefundRule (условие по сумме, признак подтверждённого клиента,
максимум прошлых возвратов, действие: автоодобрение или на согласование),
Chargeback (клиент, платёж, дата, связанный запрос). Добавь фабрики.
Сгенерируй Filament-ресурс для RefundRequest. В карточке покажи сумму, заказ,
прошлые возвраты клиента, переписку из help desk и вложения. Действия
«Одобрить», «Отказать», «На согласование» требуют причины из RefundReason
и комментария. «На согласование» требует заметки о том, что проверено.
В таблице запросов выведи оставшееся время до срока и сортируй по нему.
Добавь вкладки «Мои», «На согласовании», «Просрочено». При создании запроса
применяй RefundRule: запросы выше порога сразу уходят на согласование
руководителю, а подходящие под автоодобрение одобряются с отметкой правила.

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

После одобрения ставь в очередь фоновую задачу, которая создаёт возврат
в платёжной системе через API с ключом идемпотентности по id запроса
и сохраняет внешний id и ответ. При ошибке задача повторяется, а запрос
получает статус «Ошибка возврата». Отдельная задача загружает спорные
платежи и связывает их с отказами за последние 30 дней.
Настрой доступ: агент видит свои запросы, руководитель — все открытые,
финансы — всё и экспорт. Добавь виджеты: доля одобрений, среднее время
решения, причины отказов по неделям, спорные платежи после отказа.