Бриф для филиала: как подготовить точку сети к пилоту

Филиал готов к пилоту не после письма «стартуем в понедельник», а после проверки десяти конкретных полей: локальная цель, границы зала, люди, меню, столы, канал связи, устройства, резерв, окно запуска и доказательства готовности. Бриф собирает эти факты на одной странице.

Результат брифа — не презентация, а решение контрольной проверки: «готово» или «нужна доработка». Если критичное поле не подтверждено, точку не ругают и не запускают «как-нибудь»; ей дают владельца правки и новую дату проверки.

Если читать 30 секунд

• Бриф описывает одну конкретную точку, а не усреднённый филиал сети.
• Заполняйте десять полей фактами и ссылками на доказательства, а не ответами «есть» и «готово».
• Критичные препятствия: не назначена смена, неактуально меню, не приняты столы, нет рабочего устройства или резерва.
• Контрольная проверка заканчивается только решением «готово» либо «нужна доработка» с владельцами и сроками.
• Будущий результат пилота в бриф не записывают: он подтверждает готовность начать, а не успех.

Зачем филиалу отдельный документ

Сетевой сценарий ломается на локальных деталях. Центр знает общую цель, но может не знать, что веранда закрывается раньше, планшет делят две зоны, а нужная категория меню меняется после завтрака.

Бриф делает ограничения видимыми до запуска. Он отличается от протокола сетевого эксперимента: сетевой пилот отвечает, как сравнивать точки и переносить вывод, а этот документ отвечает, готов ли один филиал выполнить согласованный сценарий.

Хороший бриф помогает трём сторонам:

• центр сети видит, что локальные условия проверены;
• управляющий понимает объём подготовки и владельцев;
• смена получает конкретный маршрут без общих лозунгов.

Документ не должен повторять все настройки заведения. Он фиксирует только то, без чего нельзя честно начать пилот и собрать сопоставимые наблюдения.

Десять полей одностраничного брифа

Заполните поля в указанном порядке. Каждое следующее опирается на предыдущее, поэтому не начинайте с даты запуска.

1. Локальная проблема и граница проверки

Запишите одно наблюдаемое затруднение филиала и один участок, где его проверяют. «Повысить эффективность» не подходит. Подходит: «в вечернюю смену заказ за столом дважды переписывают до передачи на кухню; проверяем шесть столов основного зала».

Рядом укажите, что не входит в пилот. Например, веранда, доставка и банкетные заказы продолжают работать по старому процессу.

2. Ответственные по ролям

Нужны минимум три владельца: управляющий точки, старший пилотной смены и человек, который исправляет меню или доступность. Для каждого укажите роль, доступный канал связи и замену на случай отсутствия.

Не пишите только имена. Человек может сменить график, а обязанность должна остаться понятной следующей смене.

3. Окно пилота

Укажите календарные даты, дни недели и часы, когда новый сценарий активен. Отдельно отметьте часы, которые считаются пиковыми для этой точки по её собственному расписанию.

Если точка не может выделить наблюдателя или старшего в выбранное окно, это препятствие для запуска, а не мелкая организационная деталь.

4. Меню и локальные исключения

Зафиксируйте выбранное меню, категории пилота, владельца цены и срок обновления стоп-листа. Приложите результат контрольной сверки: несколько позиций открыты с правильными названиями, ценами, фотографиями и доступностью.

Если филиал использует локальные позиции, не скрывайте их ради «чистого» сетевого шаблона. Отметьте исключение и решите, участвует ли оно в пилоте.

5. Столы и точки входа

Перечислите метки столов или зоны, которые входят в запуск. Для каждого носителя подтвердите связь с правильным заведением и столом через контрольное открытие.

Ключи входа должны быть уникальными. Регенерация ключа делает старый напечатанный материал недействительным, поэтому после неё нужна повторная физическая приёмка.

6. Смена и доступы

Перечислите рабочие роли пилота: кто видит очередь, кто принимает заказ, кто меняет статус и кто помогает гостю. Подтвердите, что доступ относится к нужному заведению и не используется как общий пароль всей смены.

Разделение данных между точками подробнее разобрано в руководстве о границах меню, заказов и доступов сети.

7. Устройство и рабочее место

Укажите конкретное устройство, место установки, питание, сеть, громкость уведомления и рабочее расстояние. Формулировка «планшет есть» ничего не доказывает: он может лежать в кабинете, разряжаться или быть занят другим процессом.

Проведите приёмку по комплектовочной ведомости рабочего места, если точка запускает новый планшет или QR-носители.

8. Канал оперативной связи

Назначьте один канал для сообщений о сбое пилота и правило передачи вопроса ответственному. Не смешивайте технические проблемы, вопросы гостя и обычные сменные сообщения в одном потоке без меток.

Бриф должен содержать контакт дежурного со стороны точки и контакт координатора сети. Это рабочая связь проекта, а не обещание автоматических уведомлений продукта.

9. Ручной резерв

Опишите, как смена принимает и передаёт заказ при недоступном рабочем экране. Укажите место бумажного журнала, последовательность нумерации и человека, который объявляет переход на резерв.

Возврат из резерва тоже требует правила: сверить открытые записи, не создавать дубль и отметить время восстановления.

10. Доказательства готовности

В последнем поле соберите ссылки или отметки приёмки: контрольный гостевой маршрут, тестовый заказ, видимость в очереди, допустимый переход статуса, обновление доступности и срабатывание ручного резерва.

Это не метрики результата. Они лишь подтверждают, что инструменты, люди и границы точки готовы к началу наблюдения.

Шаблон, который можно перенести в рабочий документ

Скопируйте таблицу и держите ответы короткими. Для сложных материалов добавляйте ссылки, а не расширяйте бриф до многостраничного регламента.

№	Поле	Ответ филиала	Доказательство	Владелец
1	Проблема и граница
2	Ответственные
3	Окно пилота
4	Меню и исключения
5	Столы и входы
6	Смена и доступы
7	Устройство
8	Канал связи
9	Ручной резерв
10	Доказательства

Под таблицей добавьте только четыре строки:

• решение контрольной проверки;
• список препятствий;
• владелец и срок каждой правки;
• дата повторной проверки.

Не вставляйте в бриф прогноз роста заказов или экономии. Без фактических данных это не доказательство готовности, а ожидание.

Как провести контрольную проверку

Контрольную проверку лучше проводить у рабочего места, а не только по видеосвязи. Координатор сети, управляющий и представитель смены проходят поля сверху вниз и проверяют доказательства.

Порядок проверки:

1. Управляющий называет границу пилота своими словами.
2. Смена показывает рабочее устройство и резерв.
3. Координатор открывает несколько столов и позиций.
4. Команда проводит один контрольный заказ от входа до завершения.
5. Участники фиксируют препятствия, не исправляя их молча по ходу проверки.
6. Координатор объявляет одно из двух решений.

«Готово» означает, что все критичные поля подтверждены и некритичные замечания не мешают безопасному старту. «Нужна доработка» означает, что есть хотя бы одно препятствие, для которого назначены владелец, действие и новая дата.

Не используйте промежуточное «условно готово». Оно переносит спор в день запуска. Если замечание не мешает старту, запишите его как наблюдение; если мешает, решение — «нужна доработка».

Какие препятствия действительно останавливают старт

Старт откладывают, когда команда не может выполнить или восстановить основной маршрут. Критичность определяется последствиями, а не тем, насколько быстро кажется исправление.

Типовые препятствия:

• QR-вход ведёт не к той точке или столу;
• цена, состав или доступность пилотной позиции не подтверждены;
• у смены нет доступа к рабочей очереди;
• никто не владеет переходами статуса;
• устройство не держит питание или не находится у ответственного;
• ручной резерв существует только «в голове» управляющего;
• окно запуска не совпадает с присутствием подготовленной смены.

Небольшая косметическая неточность в подписи внутреннего документа может не останавливать запуск. Но неверная цена останавливает, даже если её обещают исправить за минуту: контрольная проверка фиксирует фактическое состояние на момент решения.

Как связать бриф с измерением пилота

Бриф отвечает за входные условия, а паспорт метрик — за последующее сравнение. Не смешивайте эти документы: иначе филиал начнёт «подгонять готовность» под ожидаемый результат.

Перед стартом приложите единые определения метрик первой недели. Для каждой точки должны совпадать событие, единица, окно наблюдения и правило пропусков. Локальные ограничения из брифа потом помогут объяснить различия, но не позволят менять формулы задним числом.

После проверки сохраните версию брифа. Если в середине пилота меняется зона, меню или состав смены, заведите отметку изменения. Не переписывайте исходный документ так, будто условия всегда были другими.

Изменение после решения «готово» проходит короткую повторную проверку, если затрагивает критичное поле. Новый планшет требует приёмки рабочего места, новый набор столов — проверки входов, а смена без подготовленного ответственного — пересмотра окна. Некритичную заметку можно приложить без остановки. Критерий прост: если правка меняет маршрут гостя, доступ сотрудника, источник меню или способ восстановления, прежнее доказательство больше не покрывает запуск. Координатор фиксирует, какие поля открыты снова, и не заставляет филиал повторять весь документ без причины.

Что проверяет демо и чего оно не подтверждает

В публичном демо можно увидеть только гостевую часть одной демо-точки: меню, корзину, оформление заказа и отслеживание статуса гостем. Оно не проверяет филиальный бриф, роли, рабочую очередь, устройство смены или правильность конкретного QR-входа.

Бриф остаётся вне продукта. Когда десять полей заполнены, передайте границы точки и препятствия через форму подключения. Реальные роли, входы, меню и требования сетевого запуска проверяются отдельно.

Готовность — это доказанный маршрут одной точки

Филиал готов не потому, что согласовал дату, а потому, что люди, меню, столы, устройство и резерв сходятся в одном проверенном маршруте. Одностраничный бриф удерживает эту связь и не даёт сети спрятать локальное препятствие за общим планом.

Храните принятую версию рядом с журналом изменений. Тогда новая смена увидит не только итоговый статус, но и условия, при которых он был выдан.

Заполняйте десять полей фактами, проводите контрольную проверку у рабочего места и используйте только два исхода. Тогда «готово» означает возможность честно начать пилот, а «нужна доработка» — понятный путь к следующей проверке.