«Мы вам присылали»: как журнал действий закрывает споры с клиентом

Самый неприятный спор в аутсорсинге звучит одинаково: клиент утверждает, что документ отправлял, фирма его не находит. Штраф за несданный отчёт или неучтённый расход становится предметом переговоров, а отношения портятся независимо от того, кто прав. Единственное, что закрывает такой спор быстро, это факты: когда, кто и что отправил и что с этим сделали.

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

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

Нужен независимый от людей журнал, который ведёт система.

Какие события должны попадать в журнал

Минимальный набор для системы приёма документов:

• Получение документа: дата и время, отправитель, канал (чат клиента, мини-приложение, загрузка сотрудником), исходное имя файла.
• Изменения статуса: кто и когда принял, обработал или отклонил, с каким комментарием.
• Перемещения: из какой папки в какую, кем.
• Изменение реквизитов: название, номер, дата, контрагент.
• Удаление и восстановление: отправка в корзину, восстановление, окончательное удаление.
• Доступ: кто получил доступ к клиенту, кому его отозвали, когда подключён или отключён чат.
• Действия поддержки сервиса, если она заходила в данные фирмы.

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

Почему журнал нельзя редактировать

Журнал имеет ценность, только если ему верят обе стороны. Как только у владельца фирмы или у поддержки сервиса появляется возможность исправить запись, журнал превращается в мнение. Правильная реализация работает только на добавление: записи нельзя изменить и нельзя удалить, включая администраторов.

Это же защищает фирму изнутри: ошибку сотрудника видно, и её не спишут на систему.

Как журнал работает в споре

Сценарий из практики. Клиент утверждает, что прислал накладную 3-го числа. В журнале по этому клиенту за 3-е число нет событий получения. Есть событие 11-го числа: фото получено из чата, отправитель такой-то, статус «Отклонён» с комментарием «не видно сумму», уведомление клиенту отправлено. Повторно документ пришёл 27-го. Разговор заканчивается за две минуты и без эмоций.

Обратный сценарий тоже важен. Если документ действительно получен 3-го и бухгалтер не взял его в работу, журнал покажет это. Фирма увидит проблему в процессе раньше, чем её увидит клиент.

Журнал как инструмент управления

Помимо споров, журнал даёт владельцу фирмы ответы на рабочие вопросы:

• почему документ клиента пролежал неделю и кто его должен был взять;
• кто переместил документы в другую папку перед проверкой;
• что делал уволившийся сотрудник в последний день;
• заходила ли поддержка сервиса в данные и что именно смотрела.

Для этого журнал должен фильтроваться по клиенту, сотруднику, дате и типу действия. Простой список «всё подряд» на тысячах записей бесполезен.

Что показывать клиенту

Клиенту не нужен полный журнал фирмы. Ему нужна история его документа: получен, принят, отклонён с причиной. В OkyDoky клиент видит это в мини-приложении в Telegram, а полный журнал с фильтрами по клиентам, сотрудникам и датам доступен владельцу фирмы в разделе «Аудит». Записи журнала работают только на добавление, действия поддержки записываются в журнал фирмы под отдельным актором.

Вывод

Журнал действий не про недоверие к клиенту. Он про то, чтобы спор о фактах перестал быть спором. Когда факты фиксирует система, разговор с клиентом переходит от «кто виноват» к «что делаем дальше», а это и есть нормальные рабочие отношения.