Сповіщення - остання ланка автоматизації і єдина, яку читає людина. Весь сценарій може відпрацювати бездоганно - дані приймаються, перераховуються, зберігаються, - і якщо повідомлення в кінці написане погано, процес провалюється на останніх десяти сантиметрах між екраном і рукою.
Найдешевшою правкою в усьому проєкті зазвичай виявляється формат значення в повідомленні. Найдорожчим наслідком - те, що стається, коли цю правку відкладають.
Восьмого прийшло замовлення на одинадцяте. Привезли восьмого
На проєкті інтернет-магазину з доставкою їжі замовлення йшло в повідомлення з датою, записаною так, що день і місяць можна було переплутати. Клієнт 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.
