Управляющая компания получает отчёт: точка набрала 92 балла из 100. На фотографиях всё выглядит аккуратно. При следующем визите обнаруживается прежнее замечание, а партнёр утверждает, что давно отправил подтверждение исправления в общий чат. Высокий балл скрывает незавершённое действие.
Система проверок франчайзи должна показывать не только оценку визита, но и судьбу каждого существенного замечания. Для этого нужно связать версию стандарта, наблюдение, ответственного, срок и результат повторной проверки. Чек-лист становится началом процесса, а не его конечным отчётом.
Отделите наблюдение от решения
Проверяющий фиксирует, что увидел и с каким требованием сопоставил. Затем уполномоченный участник определяет дальнейшее действие. Эти шаги не стоит объединять в поле «Нарушение», которое одновременно означает факт, интерпретацию и санкцию.
Например, на стойке отсутствует актуальный информационный материал. Наблюдение содержит место, время и фотографию. Требование указывает, какой материал должен находиться в этой точке. Решение определяет, кто заменит его и чем подтвердит результат.
Если применимость требования спорна, замечание получает соответствующий статус. Нельзя заставлять партнёра сначала признать нарушение, чтобы задать вопрос. Порядок решений и последствия несоблюдения правил определяет сама сеть; программа помогает сохранить основания и историю.
Версия стандарта важнее красивого чек-листа
У разных форматов точек могут быть разные требования. Небольшой пункт выдачи не обязан иметь те же зоны, что полноформатный магазин, если внутренний стандарт предусматривает различия.
Для каждого пункта задайте версию, период применения, допустимые форматы и понятный способ проверки. Значения «Соответствует», «Не соответствует», «Не применимо» и «Не проверено» имеют разный смысл.
Не применимо — требование не относится к точке по установленному правилу. Не проверено — вывод пока сделать нельзя. Второе нельзя автоматически считать выполнением или исключать из отчёта так, чтобы оценка стала лучше.
Изменение чек-листа не должно задним числом переписывать прошлые проверки. Сравнение периодов требует учитывать, какие пункты и правила оценки действовали тогда.
Учебный пример трёх точек
Представим условную сеть сервисных пунктов. Это пример проектирования процесса, не кейс ExtentLab. В чек-листе двадцать равнозначных пунктов, но для компактного формата два из них неприменимы.
На точке А проверены все восемнадцать применимых пунктов: шестнадцать выполнены, два нет. Если сеть выбрала простую долю выполненных, результат — 16 из 18, около 88,9%. Нельзя считать 16 из 20 и штрафовать за неприменимые условия.
На точке Б также восемнадцать применимых пунктов, но проверены только пятнадцать. Из них четырнадцать выполнены. Доля среди проверенных — около 93,3%, полнота проверки — 15 из 18, около 83,3%. Эти два числа нужно показывать отдельно.
Для точки В выявлено одно существенное замечание при высоком общем результате. По правилам учебной сети оно требует отдельного контроля независимо от баллов. Оценка не заменяет перечень открытых действий.
Карточка замечания, которую можно закрыть
Полезная карточка содержит:
- точку и конкретное место наблюдения;
- пункт и версию стандарта;
- описание факта без неопределённых оценок;
- подтверждающие материалы;
- ожидаемый результат исправления;
- исполнителя со стороны партнёра;
- согласованный срок;
- проверяющего со стороны сети;
- результат проверки и причину возврата.
Фраза «Привести в порядок» не задаёт проверяемого результата. Лучше указать, какой материал заменить, где он должен находиться и какие признаки подтвердят соответствие.
Фото может быть одним из доказательств, но не универсальным ответом. Для некоторых пунктов потребуется запись, демонстрация действия или повторный визит. Способ подтверждения выбирают по смыслу требования, а не по удобству загрузки файла.
Сообщение «исправлено» не закрывает замечание
Партнёр переводит действие в состояние «Предъявлено на проверку» и прикладывает подтверждение. Проверяющий принимает результат либо возвращает с конкретной причиной. История прежних попыток остаётся доступной.
Если срок прошёл, система показывает просрочку, но не должна самостоятельно делать вывод о причинах и последствиях. Ответственный может согласовать перенос, указав основание и новую дату. Первоначальный срок сохраняют для анализа.
Повторное выявление похожей проблемы на следующем визите лучше связывать с предыдущим замечанием. Это новый факт, а не повод молча открыть старую карточку и потерять дату повторения. Тогда видно, было ли исправление устойчивым или проблема вернулась.
Как сравнивать точки без ложного рейтинга
Сначала обеспечьте сопоставимость: формат, версия чек-листа, применимость, полнота проверки и период. Иначе рейтинг будет оценивать разные наборы требований как одинаковые.
Отдельно показывайте количество открытых существенных замечаний, долю подтверждённых исправлений и повторные проблемы. Для срока устранения различайте время работы партнёра и ожидание проверки управляющей компанией. Общая просрочка может возникнуть на любой стороне.
Не объединяйте показатели в один балл, если участники не могут объяснить его смысл. Практичнее начать с небольшого набора прозрачных величин и списка действий. Автоматический рейтинг не исправляет слабые исходные данные и неодинаковое понимание пунктов.
Самопроверку партнёра и визит представителя сети показывайте раздельно. Они могут использовать один чек-лист, но имеют разные источники наблюдений. Если в отчёте смешать эти события, руководитель не поймёт, что проверено независимо. При повторном контроле укажите, осматривалась ли точка целиком или только ранее найденные проблемы. Проверка одного исправления не подтверждает состояние всех остальных пунктов.
Готовое решение или собственная система
Конструктор проверок может закрыть задачу, если поддерживает нужные версии, роли внешних участников, работу с замечаниями и подтверждение исправлений. Проверьте эти функции на одном завершённом цикле, включая возврат результата.
Собственный модуль стоит обсуждать при существенных различиях форматов, сложной структуре партнёров, необходимости связывать проверки с действующими справочниками или особом порядке согласования исключений.
Не всякое нестандартное название статуса требует разработки. Иногда достаточно настроить готовый процесс. Но если данные о применимости и исправлениях постоянно переносят вручную между несколькими программами, стоимость такого обхода стоит сравнить с отдельным решением.
Что оставить в первой версии
Выберите один стандарт и несколько типичных форматов. Нужны версии чек-листа, назначение проверки, регистрация наблюдений, карточки замечаний, предъявление исправления и подтверждение результата.
Партнёр должен видеть только свои точки и относящиеся к нему материалы. Проверяющий — назначенные объекты, руководитель сети — доступную ему сводку. Если один партнёр управляет несколькими точками, уточните, кто отвечает за каждую и кто может назначить замену.
Сложную автоматическую оценку фотографий и большой сравнительный рейтинг можно отложить. Важнее обеспечить работу с неполными проверками, спорной применимостью и повторным замечанием: именно здесь чаще теряется смысл контроля.
Как подготовить пилот процесса
Возьмите один реальный стандарт, обезличьте две старые проверки и выберите несколько замечаний с разной судьбой. Пусть представители сети и партнёра независимо пройдут цикл и объяснят, что требуется на каждом шаге.
Проверьте изменение версии, пункт «Не проверено», перенос срока, повторную отправку подтверждения и ограничение доступа. Другой сотрудник должен восстановить причину закрытия без поиска в переписке.
Организовать участие разных ролей поможет статья о пользовательской приёмке. Для обсуждения с ExtentLab достаточно этого набора и перечня форматов точек. На его основе можно определить подходящее готовое решение либо состав заказного модуля с понятными границами первого запуска.