Уведомление - последнее звено автоматизации и единственное, которое читает человек. Весь сценарий может отработать безупречно - данные принимаются, пересчитываются, сохраняются, - и если сообщение в конце написано плохо, процесс проваливается на последних десяти сантиметрах между экраном и рукой.
Самой дешёвой правкой во всём проекте обычно оказывается формат значения в сообщении. Самым дорогим следствием - то, что происходит, когда эту правку откладывают.
Восьмого пришёл заказ на одиннадцатое. Привезли восьмого
На проекте интернет-магазина с доставкой еды заказ уходил в сообщение с датой, записанной так, что день и месяц можно было перепутать. Клиент 1 февраля 2022 попросил нас поменять порядок, и обоснование тогда было мягким: «нас это путает, один заказ у нас из-за этого пропал».
Правку тогда не сделали. 11 марта 2022 та же просьба пришла второй раз, теперь как срочная - и это уже было после заказа, который оператор прочитал неверно, и еду увезли на несколько дней раньше, чем она должна была прибыть. Между первой и второй просьбой прошло пять с половиной недель.
Когда именно формат в итоге поправили, в наших записях нет. Записана просьба, а не её выполнение, - и это тоже кое-что говорит об обращении с мелочами.
Три вещи в этом случае стоят внимания.
Во-первых, правка была технически тривиальной. Это одна строка форматирования в сообщении, а не изменение системы.
Во-вторых, ошибки не было видно в данных. В базе дата хранилась правильно. Плохо было только то, как она выглядела в сообщении, которое читает человек под давлением, с трубкой у уха.
В-третьих и самое важное: клиент подал эту просьбу как мелочь, и потому с ней и обошлись как с мелочью. Формулировка «нас это слегка путает» не прошла ни через какую очередь приоритетов. Только вторая просьба, после увезённого заказа, начиналась словом «срочно».
Телефон, на который нельзя позвонить, потому что по дороге потерялся плюс
Из того же проекта, того же месяца, второй случай - и он поучительнее, потому что его вызвала правка.
15 февраля 2022 пришло требование обработать международные номера. Мы их обработали. 19 февраля клиент сообщает: в админке у заказа показывается +420, но в сообщении, которое приходит в мессенджер, плюса нет, и на этот номер нельзя позвонить нажатием.
22 февраля нашлась причина, и она красиво незаметна: заказчики при вводе удаляли из поля код 420, потому что сами написали его второй раз. Плюс оставался. В итоге в систему проходил номер, который выглядел правильно на одном экране и не работал на другом.
Вывод не о телефонных номерах. Он о том, что правка формата создаёт следующий формат, и пока это не проверено на всём пути значения - от поля в форме через сохранение до сообщения - вы исправили только то место, куда смотрели.
Что должно быть в сообщении о заказе
Опыт обоих случаев можно записать списком. Он не длинный и ничего не стоит - это работа на час, если сделать её при постройке, и неприятный разговор, если делать после инцидента.
Дата пишется так, чтобы её нельзя было прочитать двумя способами. В сообщении для оператора это означает день недели плюс дату с месяцем словом: «четверг, 11 марта». Числовая запись 11. 3. верна и всё равно путается с 3. 11. у каждого, кто ежедневно видит и заказы из зарубежной системы. Машинно дата передаётся в однозначном формате по ISO 8601 (2026-03-11), но он относится к данным, а не к сообщению для человека.
У даты всегда написано, к чему она относится. «Заказано» и «доставить» - это в сообщении две разные даты, и в момент спешки они сливаются в одну.
У времени указан пояс, если кто-либо в процессе находится не в одной с вами стране. Полночь - самый опасный час автоматизации: у неё день сдвигается целиком.
Телефон хранится и отправляется в международном виде (формат E.164, то есть +420 и девять цифр без пробелов), и форма приводит его к этому виду сама, вместо того чтобы требовать правильную запись от заказчика. Заказчик в формат не попадёт, и у него нет причин попадать.
Номер заказа есть и в теме, и в теле сообщения. Именно по нему сообщение потом ищут, когда разбирают рекламацию.
У суммы есть валюта. Всегда, даже если вы продаёте только в одной стране, - первый заказ из-за границы придёт раньше, чем об этом кто-нибудь подумает.
В сообщении одна единица информации на строку. Уведомление никто не читает, оператор выхватывает из него глазами три значения. Сплошной абзац эту работу делает невозможной.
Тест, который вскроет большинство таких ошибок за десять минут
Ни разработчик, ни доступ в систему для него не нужны.
- Создайте тестовый заказ на одиннадцатое число месяца и получите его во все каналы, которыми пользуетесь, - почта, мессенджер, печать, админка. Одиннадцатое потому, что на нём перестановку заметишь, только если следишь; идеален же заказ от 3 числа с датой доставки 11-го, где перестановка видна сразу.
- Сравните все каналы рядом. Дело не в том, верна ли дата, а в том, везде ли она одинакова. Расхождение между каналами - это неисправность, даже если каждый из них по отдельности читается.
- Позвоните на телефон из сообщения нажатием, а не набором вручную. Так проверяется формат, а не существование номера.
- Дайте сообщение прочитать тому, кто системы не знает, и спросите его, когда заказ должен быть доставлен. Если он замешкается, сообщение написано плохо, независимо от того, что значения в нём верны.
Этот тест имеет смысл повторять после каждого изменения в формах или в уведомлениях. Второй наш случай как раз и возник из правки.
Почему мелочи такого рода откладывают
Стоит сказать вслух, потому что механизм всегда один и тот же и с качеством подрядчика не связан.
Требование изменить формат приходит сформулированным как косметика. У него нет видимой цены отказа, потому что в момент сообщения ущерба ещё не возникло. Поэтому его ставят за функциями, у которых в техзадании есть собственная строка.
Решение, которым пользуемся мы: у требований, касающихся сообщения для человека, в задание дописывается одна фраза - что произойдёт, если это прочитают неверно. «Нас это путает» и «мы привезём еду на три дня раньше» описывают одну и ту же ошибку, но встанут в очередь по-разному. Первое описание - это ощущение, второе - следствие, а очередь приоритетов понимает только следствия.
Автоматизация не заканчивается на сохранении данных. Она заканчивается фразой, которую прочитает человек, - и её тестируют так же, как всё остальное.
Хотите, чтобы мы прошли по вашим уведомлениям
Пришлите нам три настоящих сообщения, которые система шлёт вам о заказе, и скажите, кто их читает и в какой обстановке. Вернём список мест, которые можно прочитать двумя способами, и что с этим делать.
Сценарии, подключения и оповещения мы строим в разделе автоматизация. Когда числа в сообщениях расходятся с тем, что показывает система, это другая неисправность, и мы разбираем её в статье Почему в GA4 не сходится выручка.
Напишите на info@lamapixel.com или звоните +420 775 599 009.
