№22.05.2026
ПАКЕТ ДОКУМЕНТОВ
ПО LIFECYCLE И SERVICE LOG
Назначение пакета: зафиксировать целевую модель работы компании по сопровождению зарядной станции от продажи до ввода в эксплуатацию, а также по сервису, ремонту, логистике компонентов, возвратной таре и управлению ответственностью.
Ключевая идея пакета: больше логов — меньше хаоса. Запись в системе должна быть источником истины. Созвон, договоренность, оплата, дефицит, отгрузка, выезд сервисника, возврат детали и задержка считаются частью процесса только после фиксации в системе.
Политика компании по lifecycle зарядной станции
Настоящая политика устанавливает единый обязательный процесс сопровождения станции с момента согласования продажи до ввода в эксплуатацию и дальнейшего обслуживания.
1. Цель
-
создать одну сущность Station Record на всю жизнь объекта;
-
обеспечить прозрачность для клиента и для всех внутренних ролей;
-
убрать потерю информации в звонках, мессенджерах и личной памяти;
-
обеспечить передачу ответственности по цепочке с контролем accepted/completed/forwarded;
-
уменьшить простой, повторные выезды и стоимость несогласованности.
2. Базовые принципы
-
Станция создается в системе сразу после подтвержденной продажи или согласования заказа, а не после физической сборки.
-
Вся жизнь станции ведется через одну карточку и журнал событий.
-
Записи в журнале не удаляются; при ошибке создается корректирующая запись.
-
Каждая запись должна содержать: что произошло, кто сделал, кому передано дальше, что следующий шаг, когда контроль.
-
Каждая запись имеет флаг видимости: Internal only / Client visible / Client visible + Email.
-
Любое действие считается незавершенным, если оно не зафиксировано в системе.
3. Состав Station Record
-
ID станции, клиент, аккаунт клиента, страна и язык;
-
конфигурация станции: мощность, комплектация, коннекторы, GPT, DLM, modem и иные опции;
-
текущий статус и подстатус;
-
журнал событий и журнал оплат;
-
журнал логистики и журнал фотофиксации;
-
текущий ответственный, следующий шаг, ETA и дата follow-up;
-
контакты по локации, монтажу и сервису;
-
связанные документы, инструкции и шаблоны коммуникации.
4. Роли и базовая ответственность
-
Sales / продавец: согласует конфигурацию, инициирует создание станции, проверяет корректность данных, вносит стартовую запись.
-
Packer: централизованно создает карточку станции и базовую идентификацию объекта на первом этапе внедрения.
-
Finance / бухгалтерия / bot: вносит факт оплаты, процент оплаты, reference, статус списания и перевода.
-
Production / технический согласующий: подтверждает запуск в производство и передачу дальше.
-
Warehouse / комплектация: фиксирует наличие компонентов, дефицит, готовность к выдаче в сборку или сервис.
-
Assembly: фиксирует получение комплектующих, начало сборки, задержки и передачу на тестирование.
-
Testing: фиксирует получение станции, ход тестов, результаты и передачу на упаковку.
-
Logistics / Packaging: ведет упаковку, поиск перевозчика, согласование цены и отправку.
-
Installation / L2 / Ops coordinator: координирует площадку, монтаж, контакты и ввод в эксплуатацию.
-
Support: дает быстрый доступ к информации, дублирует контакты, фиксирует инциденты и помогает не допустить простоя.
5. Жизненный цикл станции
-
Согласование с клиентом и работа по публичной оферте.
-
Создание аккаунта клиента.
-
Создание station record через packer.
-
Проверка продавцом правильности station record.
-
Первая запись о согласованной конфигурации и создании станции.
-
Фиксация оплат и автоматические email-уведомления клиенту.
-
Подтверждение запуска в производство.
-
Проверка наличия компонентов / фиксация дефицита.
-
Сборка и тестирование.
-
Упаковка и поиск перевозчика.
-
Доставка на локацию и координация монтажа.
-
Ввод в эксплуатацию, настройка тарифов и активация.
6. Обязательные типы событий
client_account_created, station_configuration_agreed, station_created, station_attached_to_client_account, prepayment_received, partial_payment_received, full_payment_received, factory_transfer_sent, production_confirmed, components_available, shortage_detected, assembly_started, assembly_completed, testing_started, testing_completed, packaging_started, carrier_search_started, carrier_agreed, shipped, arrived_to_site, installation_started, installation_completed, commissioned
7. Принцип клиентской прозрачности
Клиент должен видеть не хаос, а понятный прогресс. На каждом значимом этапе клиент получает краткое, корректное и дружелюбное уведомление: что произошло, что ожидается дальше, нужно ли от него действие, каков ориентировочный срок. Клиент не должен добывать статус звонками.
8. Фотофиксация
-
фото могут добавляться и заменяться на всех этапах;
-
финальное фото на площадке должно остаться как основное;
-
допускается сохранение одной внутренней технической фотографии;
-
всегда должен быть назначен ответственный: кто делает фото и кто их загружает.
9. Обязательное правило follow-up
Каждый, кто передал процесс дальше, обязан поставить себе напоминание проверить следующий шаг. Передача без follow-up считается неполным выполнением шага.
Политика компании по сервису и ремонту
Настоящая политика определяет порядок работы по сервисным кейсам: от выявления проблемы и технического решения до замены компонента, возврата старой детали и закрытия кейса.
1. Роли в сервисном процессе
-
L2: принимает техническое решение: менять / не менять, определяет состав ремонта, дает критерии тестирования.
-
Service Manager / Service Coordinator: владеет workflow ремонта после решения L2: коммуникация, логистика, координация локации, контроль сроков.
-
Warehouse: пакует деталь, добавляет возвратную тару, оформляет outbound и inbound.
-
Service Engineer: выполняет замену, тестирует, упаковывает старую деталь на возврат.
-
Site Contact: получает деталь, передает ее сервиснику, передает возвратную коробку курьеру.
-
Support: дает быстрый доступ к контактам, инструкции и фиксирует сбои коммуникации.
2. Граница ответственности L2
L2 не должен быть диспетчером всего сервиса. L2 обязан: поставить техдиагноз, зафиксировать короткую выжимку, определить состав работ и тесты. L2 не обязан вручную вести склад, возвратную тару, follow-up по курьерам, логистику и контакты локации. Это контур Service Manager / Coordinator.
3. Правило контроля по цепочке
Кто последним поставил задачу следующему участнику, тот отвечает за контроль движения задачи до получения одного из подтверждений: accepted, completed или forwarded. Задача не считается ушедшей из зоны контроля постановщика, пока нет подтвержденного принятия или результата.
4. Сервисный поток работ
-
Проблема выявлена и зафиксирована в сервисном кейсе станции.
-
L2 анализирует материалы и пишет техническое решение.
-
Если нужно, клиент уведомляется о составе работ, стоимости и сроке.
-
После подтверждения запускается логистика детали.
-
Назначаются основной и резервный контакты на локации.
-
Проводится pre-service call для сложных ремонтов; краткая выжимка ложится в кейс.
-
Сервисник приезжает, получает деталь, выполняет замену и тестирует станцию.
-
Старая деталь упаковывается в возвратную тару с возвратным лейблом.
-
Курьер забирает возврат; возврат отслеживается до поступления на завод.
-
Кейс закрывается только после выполнения работ, теста, уведомления клиента и контроля возврата.
5. Обязательные поля сервисного кейса
-
номер станции и номер сервисного кейса;
-
кто выявил проблему и когда;
-
решение L2;
-
стоимость детали и стоимость работ;
-
статус согласования с клиентом;
-
наличие детали на складе / shortage;
-
primary и backup contact на локации;
-
planned service visit date;
-
next owner и next follow-up date;
-
return box ID и return label ID;
-
статус возврата: ожидается / в пути / получено / неполный возврат.
6. Return flow и возвратная тара
-
каждая сервисная отправка с заменой детали должна идти с возвратной коробкой и возвратным лейблом;
-
склад заранее знает, что outbound на сервис — это outbound+return flow;
-
каждый ящик должен иметь ID, ожидаемую дату возврата и привязку к станции и кейсу;
-
система должна уметь показывать ящики, не вернувшиеся более 14 дней;
-
неполный возврат или отсутствие детали запускают отдельный контрольный процесс.
7. Финансовая дисциплина по возвратам
Если исполнитель оставил у себя подлежащую возврату деталь без согласования, система должна поддерживать временный hold на сумму стоимости детали до момента возврата. Возврат разблокирует сумму. Согласованное удержание детали возможно только с явной записью retained as approved spare.
8. Правило по созвонам и митингам
Любой рабочий звонок или митинг по сервисному кейсу дает value только после краткой фиксации в системе. Минимум: кто участвовал, что решили, что делать дальше, что осталось открытым. Допускается AI-выжимка с последующей проверкой и вставкой в кейс.
9. KPI сервиса
-
время от issue_reported до L2_decision;
-
время от L2_decision до client_approval;
-
время от approval до shipment;
-
время от shipment до service visit;
-
время от replacement_completed до return_received;
-
количество невозвратов > 14 дней;
-
количество кейсов без accepted;
-
количество кейсов без итоговой выжимки после созвона.
Переходный регламент внедрения и режим 'единая точка доступа'
Пока роли, зоны ответственности и SLA не закреплены по людям окончательно, действует переходный режим внедрения.
1. Цель переходного режима
Не пытаться сначала полностью распутать хаотичную историческую модель, а запустить новую целевую модель сверху вниз: сделать прототип правил, потом пригласить экспертов процесса, собрать недостающие детали и закрепить ответственность первой итерацией.
2. Принцип запуска
-
Сначала создается готовое решение в виде пакета документов.
-
Затем решение показывается экспертам процесса: сервис, склад, монтаж, operations, L2, logistics.
-
Эксперты не проектируют систему с нуля, а досыпают критичные исключения и пробелы.
-
После этого закрепляются конкретные ответственные лица по первой итерации.
-
Далее запускается MVP-процесс и корректируется уже по заметкам и фактическим отклонениям.
3. Режим 'единая точка доступа'
Пока распределение ролей не доведено до рабочего состояния, действует временное правило: все горящие кейсы, где неясно кто отвечает, проходят через одну точку доступа. Эта точка доступа принимает вопрос, сама направляет его по нужному контуру, фиксирует отклонение и добавляет его в будущий регламент.
Временное правило не заменяет целевую модель, а позволяет не завалить текущую работу, пока новая система документируется и внедряется.
4. Что обязательно внедрить в MVP
-
Station Record и Service Case внутри Station Record;
-
типы заметок: Internal / Client visible / Client visible + Email;
-
статусы accepted / completed / forwarded;
-
next owner и next follow-up date;
-
журнал оплат текстом плюс reference;
-
контакты локации: primary + backup;
-
photo log;
-
pre-service call summary;
-
part outbound, return box ID, return label ID;
-
overdue returns > 14 days;
-
hold amount по невозвратам;
-
шаблоны клиентских уведомлений.
5. Правила для публичного описания ролей
На основе настоящего пакета можно подготовить публичное описание ролей компании: что делает каждая роль, за что отвечает, с кем взаимодействует, по каким правилам работает и какие записи обязана оставлять в системе. Это может использоваться в онбординге и при найме.
6. Краткое управленческое резюме
Главный тезис пакета: подробное логирование не замедляет компанию, а сокращает стоимость несогласованности. Повторные выезды, забытые договоренности, потерянные детали, звонки в последний момент и простой людей на площадке обходятся дороже, чем минута на качественную запись в системе. Больше логов — меньше хаоса, меньше потерь и чище управляемость.
РАСПОРЯЖЕНИЕ
О внедрении единого процесса Lifecycle, Service и Calendar Control
В целях повышения прозрачности, управляемости и скорости исполнения процессов по зарядным станциям, а также для исключения потери задач, устных договоренностей и неконтролируемых задержек, вводится единый обязательный порядок ведения Station Lifecycle, Service Workflow и Calendar Control.
1. С момента согласования продажи каждая станция подлежит немедленному созданию в системе как отдельная сущность Station Record, привязанная к клиенту, конфигурации, статусу, журналу событий и ответственным лицам.
2. Любое действие по станции, клиенту, оплате, производству, логистике, монтажу, сервису, ремонту, возврату деталей и эскалациям считается исполненным только после фиксации в системе.
3. Для каждой записи в журнале станции обязательно указываются: автор, тип события, видимость, следующий ответственный, следующий шаг, ориентировочный срок и необходимость follow-up.
4. Устанавливаются три режима заметок: Internal only, Client visible, Client visible + email. Удаление заметок не допускается; исправления вносятся новой записью.
5. Вводится правило chain of responsibility: кто последним передал задачу дальше, тот обязан контролировать ее до получения accepted, completed или forwarded.
6. Техническое решение по сервисным кейсам принимает L2. Координацию исполнения, коммуникацию, логистику, контроль сроков и возвратов ведет Service Manager или назначенный Coordinator.
7. Все сервисные отправки с заменяемыми деталями оформляются с возвратной тарой и возвратным лейблом. Невозвраты, просрочки свыше 14 дней и неполные возвраты подлежат отдельному контролю и финансовому hold по утвержденным правилам.
8. Во второй итерации внедрения к заметкам Station Lifecycle обязателен модуль Calendar Control: назначение администратора из списка, создание follow-up события в Google Calendar, отправка email-invite, обратная привязка event ID к Station Record и контроль overdue.
9. Для сложных работ обязательна краткая выжимка по созвону или митингу; без записи summary в системе согласование не считается частью процесса.
10. До утверждения постоянной матрицы ролей все спорные и неясные случаи проходят через назначенную единую точку эскалации.
Поручить ответственным руководителям направлений подготовить и согласовать в рабочих группах:
1. финальную матрицу ролей и владельцев этапов;
2. SLA и сроки контроля по каждому этапу;
3. шаблоны внутренних и клиентских уведомлений;
4. MVP-поля и статусы для первой итерации внедрения;
5. порядок запуска Calendar Control как второй очереди.