Клінінгова компанія — від паперового графіку до диспетчеризації через мобільний застосунок

Бізнес працював. Не працювало масштабування.

Записи приходили у три різні WhatsApp-групи. Денний графік жив на аркуші паперу, приклеєному до стіни в офісі. Спільна таблиця намагалася відстежувати, хто має регулярні візити і яка прибиральниця призначена, але втрачала синхронізацію вже за годину після будь-якої зміни.

Симптоми були звичні для сервісної компанії, що переросла свої інструменти. Двоє прибиральниць, відправлених за однією адресою. Регулярні клієнти, забуті, коли диспетчер мав вихідний. Відгуки, які ніколи не збиралися, бо ніхто не йшов по них далі. Платежі, які витягували з клієнтів через повідомлення за тиждень після візиту. Клієнти, що дзвонили в офіс, аби дізнатися, коли приїде прибиральниця, бо іншого способу дізнатися не було.

Власники двічі пробували коробкові рішення для виїзного сервісу. Обидва рази закінчувалося нічим: продукт був загальний, команда його не приймала. Завдання нам було конкретне: побудуйте систему, яка цьому бізнесу справді потрібна, у тій формі, у якій цей бізнес справді працює, і зробіть її нудною у використанні.

Ми випустили нативні застосунки iOS і Android для клієнтів, веб-адмінку для бек-офісу і спільний бекенд, що володіє доменом.

Клієнтський застосунок — це вхідні двері. Клієнт записується на разове або регулярне прибирання, обирає об'єкт, обирає слот і платить. Він бачить очікуваний час прибуття в міру уточнення, пише прибиральниці всередині застосунку, оцінює послугу після завершення і керує збереженими картками та адресами. Регулярні записи — це окрема сутність першого класу, а не прапорець на разовому записі. Це розрізнення визначило решту моделі даних.

Веб-адмінка — це місце, де диспетчери і керівники проводять день. Календар записів, склад персоналу, призначення маршрутів, історія клієнта і фінансові звіти, які власники реально відкривають у понеділок зранку. Ми побудували її як зручну заміну настінного графіку, а не як екскурсію по всіх таблицях бази.

Бекенд володіє базою даних. Движок планування опрацьовує правила регулярності, пропуски на свята, доступність прибиральниць і виявлення конфліктів. Push-сповіщення йдуть для обох платформ, за фоновими воркерами, щоб веб-запити лишалися швидкими. Платежі та виставлення рахунків працюють через платіжного провайдера — збережена картка, депозити там, де бізнесу це потрібно, повернення з аудит-слідом.

Інтерфейс для прибиральниць живе всередині того самого мобільного застосунку, з доступом за роллю. Прибиральниця відкриває застосунок і бачить сьогоднішні візити по порядку — адресу, нотатки про доступ і відмітку про виконання. Без другого застосунку, який треба ставити, без окремого входу, без паралельної кодової бази, яку треба підтримувати. Це рішення зекономило близько місяця роботи і прибрало цілий шар можливих багів.

Усе живе в одному застосунку з однією базою даних. Ми вибрали це проти розбиття на мікросервіси, бо інженерна команда одна і домен — це один бізнес. Розбиття не дало б нічого і коштувало б власникам ще одного runbook.

• Записи приймаються у застосунку. Офісний телефон перестав бути каналом записів.
• Паперовий графік зник зі стіни. Диспетчер працює з календаря в адмінці.
• Регулярні клієнти тепер відстежувана сутність, а не пам'ять у голові. Пропуски і свята враховані.
• Прибиральниці відмічають початок і завершення зі свого телефону. Керівники бачать статус у реальному часі.
• Відгуки автоматично закривають цикл після кожного виконаного візиту, а не ніколи.
• Платежі списуються по факту виконання. Випрошування грошей через повідомлення припинилося.
• Власники беруть тижневі цифри з адмінки, а не з таблиці, яку щоразу доводилося переробляти.

Що ми свідомо відкинули

Ми не робили інтеграцію з маркетплейсами третіх сторін. Бізнес не продає через агрегатори, а їхнє додавання означало б другу модель автентифікації і другий потік звірки виплат без поточної віддачі.

Ми не випускали повноцінний чат у застосунку з історією, вкладеннями і присутністю. Клієнт і прибиральниця обмінюються короткими координаційними повідомленнями, прив'язаними до візиту, і все. Справжній месенджер — це інший продукт.

Ми не робили оптимізатор маршрутів. Диспетчер знає місто краще, ніж будь-який солвер, який ми б випустили за чотири місяці. Адмінка показує відстань і час у дорозі між точками і дає людині вирішити. Ми лишили чистий шов, щоб додати оптимізацію пізніше, якщо обсяги це виправдають.

Ми не робили програму лояльності, реферальний движок і маркетинговий CRM. Це справжні функції. Це не цей проєкт.

Кожне скорочення задокументоване. Власники знають, чого немає і чому.

Передавання

Клієнт володіє всім.

Акаунт розробника Apple і акаунт розробника Google Play — на клієнта. Код — у репозиторіях клієнта. База даних, застосунок, веб-адмінка і фонові воркери працюють на інфраструктурі клієнта під його ж рахунком. Акаунт платіжного провайдера — теж клієнта; ми ніколи не торкалися їхніх грошей.

Ми написали інструкції реагування, які потрібні черговому: як відкотити реліз, як ротувати сертифікати push-сповіщень до того, як вони протермінуються, як відновитися з резервної копії, як розблокувати зависле фонове завдання, як викласти нову збірку у тестові канали App Store і Play Store. Ми лишили короткий список відомих гострих кутів, щоб наступний інженер не спотикався об них.

Демонстрації наприкінці кожного спринту — раз на два тижні — давали власникам очі на збірку протягом усього шляху. На передаванні сюрпризів не було. Вони ведуть бізнес на цій системі з того часу, і ми їм для цього не потрібні.