Интеграции
Зачем заносить один заказ в три программы?
«У нас всё готово на завтра. Отгружаем?» Павел посмотрел на карточку заказа. Он только что подтвердил клиенту пятницу. Завтра был четверг.
Проследим за этим заказом в небольшой торговой компании. Павел отвечает покупателям, Игорь готовит отгрузки на складе. У каждого своя программа и своя запись о доставке. До последнего звонка обе записи совпадали.
Павел поправил дату у себя. В таблице склада по-прежнему стоял четверг.
О чём эта история
Откуда взялся лишний четверг
Заказ № 184 пришёл с сайта накануне. Павел открыл сообщение, перенёс адрес и время доставки в CRM, программу с карточками покупателей. Потом добавил строку в общую таблицу склада. Там Игорь смотрел, что собрать и к какому дню приготовить.
Утром клиент позвонил: в четверг принять заказ не получится, нужна пятница. Павел уточнил у Игоря, можно ли перенести доставку. Получил согласие, исправил карточку и перезвонил клиенту. Таблицу собирался поправить следом, но на второй линии уже ждали.
Через час Игорь вернулся к списку отгрузок. На бумажке возле клавиатуры была пятница. В таблице четверг. Он решил не угадывать и позвонил Павлу.
Они открыли свои окна одновременно. Номер заказа одинаковый, адрес одинаковый. Дни разные. Программы не спорили. Каждая аккуратно показывала то, что в неё записали.
Павел исправил строку. Потом проверил остальные заказы на завтра. Хотелось убедиться, что этот четверг был единственным, которому забыли сообщить о переменах.
Договорились исправлять сразу. До следующего звонка
На короткой планёрке решили: после разговора с покупателем сразу менять обе записи. Павел приклеил к монитору заметку «Не забудь склад».
Пару дней правило работало. Затем клиент уточнил не день, а интервал: приедет только после обеда. Павел внёс новое время, открыл складскую таблицу и обнаружил, что Игорь переставил в ней колонки. Пришлось искать нужную строку. В этот момент зазвонил телефон.
Павел уже не забыл про таблицу. Он вернулся к ней после разговора. Но для одного уточнения всё равно понадобились два окна, поиск заказа и ещё одна проверка. Заметка на мониторе помогала помнить работу, которую приходилось повторять.
Здесь полезно остановиться не на вопросе «как сделать Павла внимательнее», а на другом: зачем подтверждённое время вообще набирать второй раз?
Пятницу меняют в карточке. Склад получает её сам
Можно устроить передачу иначе. Павел по-прежнему согласует перенос с Игорем и покупателем. Но записывает результат только в карточке заказа. Связь между программами находит тот же номер в складской таблице и обновляет день и интервал доставки.
Посмотрим на следующий такой звонок уже с этим порядком работы. Покупатель просит пятницу с 14 до 18 часов. Павел уточняет возможность переноса, сохраняет согласованное время и видит отметку: «Передано на склад».
Игорь открывает привычный список. В строке № 184 стоит пятница, 14–18. Ему не нужно переходить в программу продаж и разбираться в истории переговоров. Павлу не нужно повторять ввод в таблице.
Интеграция здесь не новая программа, в которую придётся переселить отдел. Это настроенная передача нужных сведений между уже используемыми окнами. Сайт принимает заказ, Павел ведёт его карточку, Игорь готовит отгрузку. Повторно печатать договорённость им больше не требуется.
При этом свободное время доставки никто не выдумывает. Возможность переноса согласуют сотрудники. После согласования программа передаёт результат.
А если таблица не обновилась?
В другой раз связь со складской таблицей временно прервалась. Павел сохранил изменение, но вместо привычного подтверждения увидел: «Склад ещё не получил новое время».
Теперь он знает, что произошло. Отгрузка близко, поэтому Павел звонит Игорю. Тот получает уточнение до сборки заказа. Когда связь восстанавливается, изменение можно передать повторно в ту же строку, а не создавать ещё один заказ.
Такое поведение нужно предусмотреть при настройке. Для Павла разница простая: раньше об устаревшей записи сообщал звонок со склада. Теперь видно, какое изменение пока не дошло, и можно вовремя вмешаться.
На случай сбоя команда договаривается, кто смотрит эти сообщения. Не обязательно заставлять Павла следить за каждым успешным переносом. Внимание требуется там, где передача остановилась.
Начать с одного заказа
Для первого шага Павел и Игорь выбирают не весь учёт компании, а один маршрут: заказ с сайта, его карточку и строку склада. Проходят обычное изменение времени и отмечают, кому оно нужно.
Затем проверяют, как используемые программы умеют обмениваться сведениями. Иногда достаточно готовой настройки. В другом случае потребуется отдельное подключение. Названия программ и список передаваемых данных помогают понять объём работы до обсуждения остальных отделов.
Можно начать и без разработчика: открыть один заказ рядом с коллегой и посмотреть, сколько раз вы записываете одно и то же. Если проблема возникает ещё раньше, когда обращение остаётся в переписке, пригодится история о заявке, которую забыли после ответа. А повторяющийся перенос удобно оценить в часах работы команды.
В пятницу Игорь открывает список и готовит заказ № 184 к согласованному интервалу. Павел отвечает следующему покупателю. Они могут созвониться по действительно сложной доставке. Выяснять, какой сегодня день у одного и того же заказа, больше не требуется.