Допустим, кафе в Алматы получает через агрегатор половину выручки выходного дня. Воскресенье, 11 октября, утро. Планшет с заказами молчит. Первые полчаса администратор думает, что просто тихий день. Потом в WhatsApp кафе приходит сообщение: «Деньги списались, в приложении заказ доставлен. Где еда?»
Кухня этого заказа не видела. Агрегатор не отвечает. Клиент злится на кафе.
Сбой Яндекса 11 октября многие владельцы бизнеса в Казахстане прожили примерно так. Сервис восстановили, но вопрос остался: что делать в следующий раз, когда откажет площадка, через которую идут ваши заказы. План Б для приёма заказов, доставки и CRM дешевле всего готовить сейчас, пока всё работает.
Главное за минуту
Что сломалось
Такси, доставка еды, Лавка и самокаты Яндекса в Казахстане – из-за повреждения дата-центров компании в России.
Данные были на месте
Серверы с персональными данными стояли в Казахстане и работали. Не работала сама платформа.
Больнее всего – расхождения
Оплаченные заказы, которые не дошли до кухни, и клиенты, которые винят заведение, а не приложение.
Что сделать
Карта внешних зависимостей, второй канал заказов в CRM, своя база постоянных клиентов и порядок сверки после сбоя.
Что произошло 11 октября
Утром 11 октября в Казахстане перестали нормально работать заказ такси, доставка еды, Яндекс Лавка и аренда самокатов. Похожие сбои были в Кыргызстане, Беларуси и Армении. Yandex Qazaqstan объяснила механику так: вычислительные задачи распределяются между серверами в разных странах, при отказе их переносят на другие серверы, и ошибки связаны как раз с этими переносами. Отказали дата-центры компании в России.
К вечеру такси заработало, доставка и Лавка какое-то время шли в ограниченном режиме. Утром 12 октября сервисы работали, но с перебоями. Вице-премьер и министр искусственного интеллекта и цифрового развития Жаслан Мадиев назвал предварительный срок полного восстановления – два-три дня, оговорившись, что это прогноз, а не гарантия.
Сама компания главным приоритетом назвала платежи и инструменты поддержки для пользователей и партнёров. Это показательно. Пользователи жаловались на списанные деньги за заказы, которые в приложении отмечены выполненными, на пропавшую историю заказов и недоступную поддержку. Были сообщения, что ресторан так и не получил оплаченный заказ. Это жалобы из соцсетей, а не статистика. Но для заведения каждая такая жалоба – конкретный гость, который запомнит не название приложения, а название кафе.
Данные в Казахстане – ещё не работа в Казахстане
Вечером 11 октября министерство сообщило: серверы с персональными данными казахстанских пользователей размещены в стране и работают штатно. При этом отдельные компоненты, без которых не работают такси и доставка, находятся за пределами Казахстана. Министерство прямо разделило две задачи: хранить данные в стране и обеспечивать стабильную работу платформы – это разные вещи, и каждая требует своего решения.
Мы считаем эту фразу самым полезным, что бизнес может вынести из истории со сбоем Яндекса. И касается она не только агрегаторов.
Когда компания выбирает CRM или чат-бота, про хранение данных спрашивают почти всегда – этого требует закон, подробнее мы писали в статье «Новые правила защиты персональных данных: что проверить в CRM». А вот вопрос «где работает то, без чего система не откроется» не задают почти никогда. Хотя адреса здесь разные: база клиентов может лежать в Алматы, а вход в систему, отправка сообщений в мессенджеры, языковая модель бота и облачная АТС – в трёх других странах.
Карта зависимостей: что у вас работает за границей
Начните с одной таблицы. Пройдите путь заказа от первого сообщения клиента до закрытой сделки и запишите, через какие внешние сервисы он проходит и что будет, если один из них отключится на сутки. Для кафе или интернет-магазина картина обычно такая:
| Звено | Что ломается при отказе | План Б |
|---|---|---|
| Агрегатор доставки или маркетплейс | Пропадает поток заказов, связь с курьером и часть оплат | Свой канал заказов в мессенджере, второй агрегатор, договорённость с курьерской службой на пиковые часы |
| Мессенджер и его API | Бот и операторы не получают сообщений | Второй мессенджер, переадресация на телефон, сообщение о сбое в соцсетях |
| Языковая модель бота | Бот молчит или отвечает ошибкой | Запасная модель у другого поставщика или сценарий «сразу передать оператору» |
| Облачная CRM | Не видно заказов, клиентов и задач | Регулярная выгрузка базы и открытых заказов, понятный ручной режим |
| Облачная АТС | Не проходят входящие звонки | Переадресация номера на мобильные телефоны |
| Онлайн-оплата | Нельзя принять предоплату | Второй способ оплаты: QR, ссылка на оплату, оплата при получении |
Дублировать всё подряд не нужно, это дорого и бессмысленно. Отметьте звенья, без которых бизнес не может принимать заказы дольше часа. План Б нужен только для них, остальное переживёт полдня ручной работы.
Второй канал заказов: что подготовить заранее
За час во время сбоя свою доставку не запустить. Но можно заранее подготовить второй вход для заказов и включать его, когда первый ломается. Для кафе или магазина это несколько вещей:
- Номер WhatsApp или Telegram-бот с меню, который принимает заказ и создаёт карточку в CRM. Как это устроено у ресторанов, мы разбирали в статье «Как рестораны принимают заказы и бронируют столы через WhatsApp».
- Способ оплаты без агрегатора: QR-код или ссылка, которую бот или администратор отправляет клиенту.
- Курьеры на пиковые часы: договор с курьерской службой или свои водители, список зон доставки и цен.
- Готовый текст для клиентов: «Доставка через приложение сейчас не работает, заказ можно оформить здесь».
- Своя база постоянных клиентов в CRM с согласием на сообщения.
Последний пункт – самый важный и самый неочевидный. Клиенты агрегатора принадлежат агрегатору: их контакты у заведения обычно не остаются. Если в CRM нет собственных постоянных гостей, которые разрешили вам писать, во время сбоя сообщить о втором канале просто некому. Поэтому каждый заказ, пришедший напрямую, стоит сохранять в CRM с согласием – это и есть ваша страховка на следующий сбой.
Второй канал заказов с записью в CRM
Покажем на вашем меню, как бот в WhatsApp принимает заказ, отправляет ссылку на оплату и создаёт карточку в CRM.
Сверка после сбоя: оплачено, но не доставлено
Сбой заканчивается, а разбор только начинается. Самое неприятное, что оставляет такой день, – расхождения. Агрегатор считает заказ выполненным, клиент заплатил, а кухня его не видела. Если ждать, пока клиенты напишут сами, часть из них просто уйдёт к конкурентам и не вернётся.
Порядок разбора лучше записать заранее, чтобы в день сбоя не придумывать его на ходу:
- Как только кабинет партнёра заработает, выгрузить заказы за период сбоя.
- Сопоставить их с кассой и CRM: что приготовлено и передано курьеру, что нет.
- Спорные заказы завести в CRM отдельными задачами с ответственным и сроком.
- Написать клиентам первыми, если контакт есть. Если нет – передать список в поддержку площадки.
- Записать цифры: сколько часов простоя, сколько заказов потеряно, сколько спорных.
Последний шаг часто пропускают, а зря. Цифра простоя нужна для претензии площадке – условия компенсаций зависят от вашего договора, и перечитать его стоит сейчас, пока сбой свеж в памяти. И она же нужна, чтобы посчитать, сколько разумно тратить на план Б. Без неё резервный канал так и останется хорошей идеей.
Чего план Б не даст
- Трафик агрегатора он не вернёт: новые клиенты ищут еду в приложении, а не ваш WhatsApp. Второй канал удерживает своих, а не приводит чужих.
- Свой бот тоже зависит от внешних сервисов – мессенджера, языковой модели, хостинга. Резервировать нужно и его, об этом подробно в материале «План B: как обеспечить непрерывность сервиса, если AI недоступен».
- Резерв стоит денег: второй договор с курьерами, абонентская плата, время на поддержку. Считайте его от стоимости часа простоя, а не от страха.
- Хранение данных в Казахстане не защищает от отказа. Это требование закона, а не гарантия, что сервис будет доступен.
Что спросить у поставщика CRM и бота
История с Яндексом – хороший повод задать своим подрядчикам вопросы, которые обычно остаются за кадром при покупке. Ответы на них лучше получить письменно:
- Где хранятся данные клиентов, и где работают сервисы, без которых система не откроется?
- Что произойдёт, если недоступна языковая модель, API мессенджера или облачная АТС: бот замолчит или передаст диалог оператору?
- Можно ли быстро выгрузить базу клиентов и открытые заказы, и в каком формате?
- Кто и как сообщит нам о сбое – или мы узнаем о нём от клиентов?
Здесь обычно спорят: «у нас никогда не падало». Возможно. Но 10 октября так сказали бы и про Яндекс.
План на эту неделю
Большой проект не нужен. Хватит пары рабочих дней, если разбить задачу на короткие шаги:
- Нарисовать путь заказа и отметить звенья, без которых бизнес стоит дольше часа.
- Подготовить второй канал заказов и текст сообщения о сбое.
- Начать собирать в CRM собственную базу постоянных клиентов с согласием на сообщения.
- Записать порядок сверки заказов после сбоя и назначить ответственного.
- Отправить поставщикам CRM и бота четыре вопроса из списка выше.
Когда следующий сбой случится – у агрегатора, мессенджера или поставщика модели, – разница будет видна сразу: одни будут ждать восстановления, другие продолжат принимать заказы.
Связанные материалы
Соберём план Б до следующего сбоя
Пришлите схему, как к вам сейчас приходят заказы. За неделю составим карту зависимостей, подключим второй канал заказов в WhatsApp с записью в CRM и настроим сверку после сбоя.