Документи по lifecycle і service log

№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.

З моменту погодження продажу кожна станція підлягає негайному створенню в системі як окрема сутність Station Record, прив’язана до клієнта, конфігурації, статусу, журналу подій та відповідальних осіб.
Будь-яка дія щодо станції, клієнта, оплати, виробництва, логістики, монтажу, сервісу, ремонту, повернення деталей та ескалацій вважається виконаною лише після фіксації в системі.
Для кожного запису в журналі станції обов’язково зазначаються: автор, тип події, видимість, наступний відповідальний, наступний крок, орієнтовний строк та необхідність follow-up.
Встановлюються три режими нотаток: Internal only, Client visible, Client visible + email. Видалення нотаток не допускається; виправлення вносяться новим записом.
Запроваджується правило chain of responsibility: той, хто останнім передав задачу далі, зобов’язаний контролювати її до отримання accepted, completed або forwarded.
Технічне рішення щодо сервісних кейсів приймає L2. Координацію виконання, комунікацію, логістику, контроль строків та повернень веде Service Manager або призначений Coordinator.
Усі сервісні відправлення із замінними деталями оформлюються із зворотною тарою та зворотним лейблом. Неповернення, прострочення понад 14 днів та неповні повернення підлягають окремому контролю та фінансовому hold відповідно до затверджених правил.
У другій ітерації впровадження до нотаток Station Lifecycle обов’язковим є модуль Calendar Control: призначення адміністратора зі списку, створення follow-up події в Google Calendar, надсилання email-invite, зворотна прив’язка event ID до Station Record та контроль overdue.
Для складних робіт обов’язковою є коротка вижимка за результатами дзвінка або мітингу; без запису summary в системі погодження не вважається частиною процесу.

10. До затвердження постійної матриці ролей усі спірні та неясні випадки проходять через призначену єдину точку ескалації.

Доручити відповідальним керівникам напрямків підготувати та погодити в робочих групах:
1.фінальну матрицю ролей та власників етапів;
2.SLA та строки контролю для кожного етапу;
3.шаблони внутрішніх та клієнтських повідомлень;
4.MVP-поля та статуси для першої ітерації впровадження;
5.порядок запуску Calendar Control як другої черги впровадження.

Завантажити розпорядження

ПАКЕТ ДОКУМЕНТІВ ЩОДО LIFECYCLE ТА SERVICE LOG