Мобільний застосунок для автосервісу: де обривається запис
Клієнт телефонує на приймальню в розпал зміни: адміністратор на видачі, майстер під підйомником, лінія зайнята, передзвонити нікому. За годину людина записується туди, де слухавку взяли з першого разу, а слот, що звільнився в розкладі поста, так і залишається невидимим для всіх.
Далі збій накопичується. Машина вже в роботі, але статус ремонту автомобіля клієнт отримує лише дзвінком — тими самими дзвінками, які приймальня не встигає брати. Пропущені дзвінки на приймальню зростають не тому, що адміністратор повільний, а тому що канал один: голос.
З боку цеху це виглядає як нерівне завантаження постів автосервісу. Ранок перевантажений, вікно після обіду порожнє, майстер дізнається про перенесення в момент, коли машина вже піднята на підйомнику, а узгодження додаткових робіт іде навпомацки.
Причина не в дисципліні — між клієнтом, приймальнею і постом немає єдиного стану запису: слот живе в одному журналі, робота в іншому, статус у третій голові.
Запис в автосервіс онлайн, сповіщення про зміну статусу й онлайн-завантаження постів — це не «ще один застосунок», а одна модель даних: слот, виконавець, етап робіт і клієнт пов'язані в один запис, і будь-яка зміна в ній одразу видна всім учасникам. Нижче розбираємо, як це закривається.
Що змінює запуск: запис, статуси, повторні візити
Запуск застосунку виправданий не інтерфейсом, а тим, що частина роботи приймальні виходить з телефонії. Ефект ми вимірюємо за метриками з аналітики та журналів заявок, а базові значення фіксуємо до релізу — інакше поліпшення нічим підтвердити.
- Частка записів без дзвінка — скільки слотів клієнт зайняв сам: послуга, дата, пост, підтвердження. Видно, яка частина первинного потоку перестала проходити через телефон приймальні.
- Час відповіді на заявку — від надсилання форми до підтвердження майстром. Дивимося не середнє, а хвіст: затримки в години пік б'ють по лояльності сильніше за загальну статистику.
- Сповіщення про готовність автомобіля — як швидко клієнт дізнається про зміну статусу і скільки вхідних «ну що там з машиною» залишилося в приймальні. Це прямі зекономлені хвилини на кожному замовленні-наряді.
- Повторні візити клієнтів — частка тих, хто повернувся на наступне обслуговування за нагадуванням із застосунку, а не після обдзвону адміністратора.
- Зниження навантаження на приймальню — скільки заявок співробітник веде без втрати якості й скільки хвилин на день звільняється на живі консультації.
- Збіжність з обліковою системою — статуси, замовлення-наряд і історія робіт підтягуються із системи сервісу через обмін з 1С, дані не заводять вручну двічі.
Метрики знімаємо на одному зрізі: кілька тижнів до запуску і той самий період після. Якщо пункт не рухається, розбираємо воронку — де саме клієнт відвалився: на виборі слота, підтвердженні чи статусі.
Формат продукту: кросплатформний, нативний, веб
Автосервісу потрібні три речі: клієнт записується на зручний час, бачить статус робіт і отримує сповіщення, коли машина готова. Різниця між варіантами розробки не в наборі екранів, а в тому, до яких можливостей телефона є доступ і скільки коду доводиться підтримувати паралельно.
Вододіл проходить по сповіщеннях і роботі без мережі. Системні канали доставки надійно працюють лише в установленого застосунку: вони піднімають екран, навіть коли програма закрита.
Веб-версія залежить від відкритої вкладки, тому критичний статус «машина готова» через неї легко губиться.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кросплатформна розробка, єдина кодова база | Запис, історія візитів, статуси, сповіщення — екрани й логіка збігаються на обох платформах | Важка графіка та нестандартні модулі потребують нативних вставок |
| Нативний застосунок під кожну платформу | Потрібні камера, сканери, робота без мережі в майстра, глибокі системні інтеграції | Дві гілки коду, дві команди, випуски синхронізуються вручну |
| Веб-версія для клієнтів | Вхід без установки, разові записи, сторінка запису з телефона | Сповіщення не надходять при закритому браузері, частина системних функцій недоступна |
На практиці обирають комбінацію: єдина кодова база закриває запис, історію та статуси, нативний клієнт додає те, що потребує прямого доступу до пристрою, а веб-версія залишається точкою входу для тих, хто не хоче нічого встановлювати. Такий набір описуємо на старті — щоб не переписувати продукт при появі нових сценаріїв.
Як ми ведемо проєкт: від розбору процесів до релізу
Мобільний застосунок для автосервісу ламається не на екранах, а на стику з обліковою системою сервісу. Заявка із застосунку має стати в той самий графік постів і майстрів, що й запис по телефону, — інакше адміністратор веде два розклади вручну й звіряє їх із пам'яті. Тому починаємо з розбору процесів сервісу і лише після цього пишемо код.
- Розбір процесів і ролей. Дивимося, як приймають машину, хто переносить запис, що роблять при відмові клієнта, — і фіксуємо це як схему статусів заявки, єдину для застосунку й облікової системи.
- Схема даних і точки інтеграції. Визначаємо, які сутності залишаються джерелом правди в системі обліку, що кешується в застосунку, а що запитується на місці.
- Прототип обміну. Збираємо мінімальний контур: створення заявки, підтвердження слота, зміна статусу. Перевіряємо ідемпотентність — повторне надсилання при обриві зв'язку не повинно породити другий запис.
- Складання клієнтської частини. Запис, історія обслуговування, статуси ремонту, push-сповіщення про готовність. Стан синхронізації видно користувачеві: заявку надіслано, прийнято, підтверджено.
- Тестування сценаріїв запису. Проганяємо конфлікти слотів, подвійні бронювання, скасування за годину до візиту, роботу без мережі. На знеособленій копії бази сервісу, а не на вигаданих даних.
- Пілот на одній філії. Дивимося живий потік: скільки заявок доходить без дзвінка адміністратора і де рветься зв'язок із системою обліку.
- Передача проєкту замовнику. Конфігурації, схема інтеграції, регламент випуску оновлень і навчання команди сервісу роботі із заявками.
Що залишається в сервісу: код, доступи, регламенти
Проєкт закінчується не демонстрацією на телефоні, а передачею всього, з чого застосунок складається: сервіс залишається власником коду, акаунтів і правил роботи. Ми перевіряємо це до закриття проєкту — якщо хоч один пункт не передано, робота не вважається зданою.
- Вихідний код у репозиторії: обидві платформи, історія змін, гілки релізів, права власника на читання й запис; передача фіксується актом, а не листом у месенджері.
- Складання й випуск версій: де лежать ключі підпису, як зібрати релізну збірку, як викласти оновлення в магазини застосунків.
- Документація застосунку: схема модулів, опис потоку запису й статусів замовлення, карта зовнішніх сервісів — системи обліку, телефонії, оплати, надсилання сповіщень.
- Права доступу адміністратора сервісу: матриця ролей — майстер, адміністратор, керуючий; хто створює запис, переносить, скасовує, бачить історію та вивантажує звіт.
- Регламент роботи із записами: порядок при перенесенні, неявці, запізненні та закритті замовлення; який статус у який момент ставить співробітник і яке сповіщення надходить клієнту.
- Інструкції для співробітників: короткі посібники по кожному робочому місцю, від приймання машини до закриття замовлення.
- Регламент оновлень: як випускається нова версія, у якому порядку оновлюється застосунок і як відкотитися на попередню збірку при збої.
Доступи видаються на ваші акаунти в магазинах застосунків і на серверній стороні, тому зміна підрядника не перетворюється на відновлення системи за уривками листування.
Кейс: мережа автосервісів — записи без дзвінка та статуси
Кейс мобільного застосунку для мережі автосервісів почався з вузького місця в розкладі: записи приймали лише по телефону. У пікові години оператор не встигав — клієнт додзвонювався з другої-третьої спроби, а слоти простоювали після скасувань. Уточнювальні дзвінки «машина готова?» з'їдали помітну частину часу адміністраторів.
Що змінили
Ми зробили застосунок, де клієнт обирає послугу, бачить вільні слоти по конкретному посту й підтверджує запис сам. Слот займається в розкладі одразу і при скасуванні звільняється для наступного в черзі — простої не накопичуються.
Статус робіт змінюється на боці сервісу: «прийнято», «у роботі», «готово до видачі» — і надходить клієнту push-повідомленням. Запис додається в календар телефона (Google Календар) однією кнопкою.
Що показали метрики
Частка онлайн-записів зросла з 14% до 71%, решта — складний ремонт і узгодження кошторисів. Середній час від звернення до підтвердженого слота скоротився з кількох годин до хвилин: раніше клієнт чекав на оператора, тепер слот підтверджується в момент вибору.
Кількість уточнювальних дзвінків про статус упала приблизно втричі — статус видно в застосунку, а push надходить у момент зміни етапу.
Навантаження на кол-центр перерозподілилося: оператори узгоджують кошториси та запчастини замість перенесення записів. Повторні звернення клієнтів зросли — людина повертається туди, де запис займає хвилину і не потребує уточнень.
Далі розвиваємо нагадування про регламентне обслуговування: вони повертають у сервіс до потрібного пробігу, а не коли щось зламалося.
Що робити, якщо в сервісу вже є облікова система?
Облікова система залишається джерелом правди: замовлення-наряди, історія робіт по автомобілю та довідник послуг живуть у ній. Мобільний застосунок — не заміна обліку, а ще один клієнт, який читає й пише дані через інтеграційний шар.
Міняти систему заради запису з телефона не потрібно, якщо вона віддає дані назовні — наприклад, 1С через опублікований інтерфейс або доступ до бази.
Обмін даними про записи йде в обидва боки: назовні — вільні слоти, статуси замовлень-нарядів і узгодження, усередину — новий запис, перенесення та скасування.
Довідник послуг переноситься один раз при запуску: категорії, роботи, нормативні тривалості, прив'язка до постів і майстрів. Далі синхронізація йде за змінами, а не повним перезаливанням каталогу — інакше довідник розходиться з обліком після першої ж правки.
| Варіант підключення | Коли підходить | Обмеження |
|---|---|---|
| Прямий обмін через програмний інтерфейс системи | У системи відкритий інтерфейс і описи методів | Частина полів збирається з кількох викликів, не всі системи віддають слоти |
| Проміжна служба обміну | Облік закритий або систем кілька | Ще один компонент: його супроводжують і стежать за затримкою обміну |
| Регулярні вивантаження | Стара система без інтерфейсу, потік записів невеликий | Запис видно із затримкою, при одночасній правці можливі конфлікти |
| Обмін напряму з базою | Доступ узгоджено, схема стабільна | Оновлення облікової системи ламає обмін, потрібен окремий контур |
Окремий ризик — обрив зв'язку на приймальні або в цеху. Заявки йдуть не в момент натискання, а стають у локальну чергу заявок на пристрої й надсилаються при відновленні каналу.
Кожна позначена ідентифікатором, тому повторне надсилання не створює дубль, а клієнт бачить підтвердження запису лише після відповіді облікової системи.
Який із варіантів реалістичний у вашому випадку, залежить від того, що система вміє віддавати сьогодні. Опишіть, яка у вас облікова система і хто нею володіє — повернемося з оцінкою та планом підключення.
Технічні питання перед стартом розробки
Перед стартом замовники ставлять одні й ті самі чотири питання: що буде після запуску, як виходять оновлення, що побачить майстер без мережі й кому належить готовий застосунок. Відповідаємо коротко — деталі розбираємо на дзвінку.
Яка підтримка буде після запуску?
Підтримка — це регламент, а не «доопрацювання за залишковим принципом»: чергування, моніторинг збоїв і падінь, оновлення під нові версії мобільних систем. На критичну відмову реакція вимірюється годинами, а не днями, і у вас є журнал звернень із фактичними строками закриття.
Як випускаються оновлення?
Складання йде автоматично після перевірок, публікація — поетапно: спочатку нова версія йде невеликій частці користувачів, дивимося на частку падінь і швидкість відгуку, потім розкочуємо на всіх. Відкат — повернення попередньої версії.
Частина вмісту (правила запису, тексти, статуси) правиться на боці сервера й доходить до майстрів без випуску нової версії застосунку.
Застосунок працює без мережі?
Частково й усвідомлено: картки заявок, історія робіт і статуси доступні з локального сховища, бо в боксі зв'язок нестабільний. Нові записи та зміни статусу складаються в чергу й ідуть на сервер при появі каналу.
При синхронізації діє правило «остання зміна за часом сервера» — два майстри не перепишуть статус один одного. Сповіщення дедуплікуємо: одна подія — одне повідомлення, навіть якщо воно прийшло і каналом даних, і при відкритті застосунку.
Кому належать права на застосунок?
Вам. Акаунти в магазинах, ключі підпису, репозиторії та серверні налаштування оформлюються на замовника з першого дня.
Передача — це не вивантаження архіву, а доступи, документація зі складання та інструкція з випуску: після неї роботу продовжують ваша команда або інший підрядник без нашої участі.
Обговоримо задачу: запис, статуси, сповіщення
Щоб обговорення задачі розробки йшло предметно, а не на рівні «хочемо зручно й красиво», корисно прийти з кількома вступними. Готувати їх заздалегідь не обов'язково — половину питань розберемо разом.
Але якщо щось зі списку є під рукою, оцінка строків розробки й план робіт із застосунку вийдуть точнішими з першого проходу, без зайвих кіл уточнень.
- Як ведете запис зараз: дзвінок, месенджер, таблиця чи облікова система — і на якому кроці найчастіше губиться заявка.
- Повний набір статусів замовлення: прийнято, у роботі, чекає деталь, готово, видано — і хто зі співробітників перемикає їх вручну.
- Які сценарії запису потрібні: вибір поста й майстра, вільні вікна, перенесення та скасування візиту, повторне звернення по тому самому авто.
- Що й кому надходить у сповіщеннях: клієнту — підтвердження та готовність автомобіля, майстру — новий запис, керівнику — завантаження на день.
- Дані, з якими працюєте: історія візитів, номери та марки авто, чи потрібно підтягувати їх із наявної системи або заводити заново.
- Хто на вашому боці приймає результат і на чому перевіряємо: тестові акаунти, перелік сценаріїв, доступи до системи запису.
- Обмеження, які не можна зсунути: дата запуску, кількість точок обслуговування, ролі співробітників з різними правами.
Зі свого боку повертаємося оцінкою строків розробки та планом робіт із застосунку: розбивка за сценаріями запису й статусів, що робимо першим, де потрібні дані або доступи від вас. Опишіть задачу у вільній формі — цього достатньо, щоб почати розбір.
