Чим глибше компанія автоматизована, тим більше вона залежить від того, що все працює. Це нормальна ціна: система економить години щодня. Але вона змінює характер аварії — коли записи велися в зошиті, збій означав загублений аркуш, а тепер він означає, що робота зупиняється вся одразу.
Хороша новина: аварійний план — це не проєкт. Це кілька домовленостей, які записують за пів дня й переглядають раз на рік.
Що саме може стати недоступним
Не варто планувати «збій системи» загалом — корисніше розібрати чотири окремі сценарії, бо дії в них різні:
- Немає сайту. Заявки не надходять, реклама витрачається даремно.
- Немає CRM або облікової системи. Заявки надходять, але їх нема куди записувати й незрозуміло, з ким уже говорили.
- Зламалася інтеграція. Зовні все живе, але дані між системами не ходять: замовлення не потрапляють в облік, залишки не оновлюються. Найпідступніший випадок — про нього матеріал про моніторинг інтеграцій.
- Немає інтернету чи світла в офісі. Системи працюють, недоступні саме ви.
Останній сценарій найчастіший і найлегший — його закриває телефон із мобільним інтернетом і доступ із дому.
Мінімальний план на одному аркуші
Аварійний план — це відповіді на пʼять питань. Не більше.
1. Куди записуємо нові заявки. Одне конкретне місце: спільна таблиця, окремий чат, зошит на рецепції. Головне — щоб воно було одне на всіх, інакше після відновлення половина заявок загубиться.
2. Звідки беремо дані на сьогодні. Список замовлень у роботі, контакти клієнтів, з якими домовлено на найближчі дні. Практичний прийом: вивантаження на день уперед, яке формується автоматично й лягає в доступне місце.
3. Хто що робить. Одна людина повідомляє команду й клієнтів, друга звʼязується з підрядником, решта працює за планом. Ролі мають бути названі поіменно.
4. Що говоримо клієнтам. Заготовлені два-три речення без технічних подробиць: працюємо, замовлення приймаємо, підтвердження надішлемо трохи пізніше. Цього достатньо.
5. Як повертаємося назад. Хто й у якому порядку переносить зібране в систему, хто перевіряє, що нічого не задвоїлося.
Аркуш має існувати поза системою — надрукований або у файлі в телефоні. План, доступний лише всередині CRM, у потрібний момент недоступний за визначенням.
Що підготувати заздалегідь
Резервні копії, які хтось перевіряв. Копія, яку ніколи не відновлювали, — це припущення, а не копія. Порядок перевірки — у матеріалі про резервне копіювання сайту.
Контакти підрядника з реальним часом реакції. Не «пишіть на пошту», а конкретна людина, номер і домовленість, за скільки вона відповідає в робочий і неробочий час. Про що варто домовитися заздалегідь — у матеріалі про підтримку системи після впровадження.
Доступи не в однієї людини. Класична ситуація: усе працює, але єдиний, хто має адміністративний доступ, у відпустці. Як це розводити — у матеріалі про права доступу співробітників.
Сповіщення, які приходять вам, а не клієнту. Про падіння ви маєте дізнаватися першим — механіка в матеріалі про сповіщення команді про події.
Найдорожча помилка — мовчання
У більшості випадків клієнт не памʼятатиме, що ваш сайт кілька годин не працював. Він памʼятатиме, що йому не відповіли й нічого не пояснили.
Тому перше, що робиться під час збою, — не пошук причини, а повідомлення: коротке, спокійне, з обіцянкою написати ще раз. Що саме розміщувати на сайті, коли він частково живий, — у матеріалі про те, що робити, якщо сайт не працює.
Повернення в норму — окремий етап
Момент, коли все запрацювало, помилково вважають кінцем аварії. Насправді далі найризикованіше: перенести зібране вручну так, щоб не зʼявилися дублі й не загубилися заявки.
Порядок, який працює: спершу перенести нові заявки, потім оновити статуси наявних, потім звірити оплати, і тільки після цього повертати автоматичні розсилки й нагадування — інакше клієнти отримають серію застарілих повідомлень. Як не наплодити дублів під час ручного перенесення — у матеріалі про дублі в базі клієнтів.
Наприкінці — короткий розбір: що саме сталося, скільки тривало, що зробити, щоб не повторилося. Пʼятнадцять хвилин розмови економлять наступну аварію.
Як перевірити план, не чекаючи біди
Найпростіше — навчання на пів години раз на рік: оголосіть, що системи «немає», і попрацюйте так одну годину. Зазвичай уже на десятій хвилині зʼясовується, що список клієнтів на сьогодні взяти нізвідки, а телефон підрядника знає тільки одна людина.
Це дешевший спосіб знайти дірки, ніж справжній збій. Знайдене одразу дописується в аркуш і в загальну базу знань для команди.
Коротко
План Б — це один аркуш поза системою: куди записуємо заявки, звідки беремо дані на день, хто що робить, що говоримо клієнтам і як повертаємося назад. Підготуйте перевірені копії, розведіть доступи між людьми, домовтеся з підрядником про час реакції. І хоча б раз на рік перевірте план на практиці — саме там знаходяться його дірки.
Ми в Obliko впроваджуємо системи разом із порядком дій на випадок, коли вони недоступні.
Наскільки ймовірно, що система буде недоступна?
Повні відмови рідкісні, але не виняткові: збій хостингу, проблема в провайдера, помилка після оновлення, відключення світла чи звʼязку. Кілька годин простою на рік — реалістичний сценарій для будь-якої компанії.
Що має бути в аварійному плані мінімально?
Куди записувати нові заявки, звідки взяти контакти клієнтів на сьогодні, хто повідомляє команду, хто звʼязується з підрядником і як потім перенести зібрані дані в систему.
Чи потрібен паперовий варіант плану?
Потрібен один надрукований аркуш або файл у телефоні. План, який лежить тільки всередині недоступної системи, не існує в момент, коли він потрібен.
Хто має відповідати за дії під час збою?
Одна названа людина з правом ухвалювати рішення й одна запасна. Без цього перші пів години йдуть на зʼясування, хто що робить, — а це найдорожчі пів години.
Рутина зʼїдає робочий день?
Подивимось ваші процеси й порахуємо, що автоматизувати першим, щоб віддача була найшвидшою.