Ми не просто побудували
маркетплейс.
Ми його запустили.
ChiliAuto з'єднує бригади переїзду з клієнтами по всій Празі. Два мобільних застосунки, движок диспетчеризації в реальному часі, платежі Stripe Connect, двостороння система рейтингів і операційна панель — все живе, все підтримується тією ж командою, що його побудувала.
Компанія з переїздів переросла WhatsApp.
Операція працювала, але трималася на силі волі засновників. Бронювання надходили телефоном. Призначення бригад відбувалося через WhatsApp-групи. Відстеження доступності жило в спільній таблиці, яка завжди відставала на одне редагування. Платежі — готівка або банківський переказ, які доводилося витребовувати після роботи.
Коли кількість бригад зросла з трьох до шести, витрати на координацію зростали швидше. Кожна додаткова бригада додавала нові граничні випадки: бронювання, що перетинаються, неявки, невідповідність відстаней. Засновник витрачав чотири години на день на логістику диспетчеризації, яка мала бути автоматичною.
Спочатку пропозиція. Завжди.
Ми провели перші два тижні в дискавері — інтерв'ювали координатора диспетчеризації, супроводжували два реальних переїзди і картували кожну точку збою в існуючому робочому процесі. Ключовий інсайт, що визначив все: сторона попиту марна без надійної сторони пропозиції. Клієнти не бронюють, якщо бригади не з'являються.
Ми побудували застосунок для бригади (сторона пропозиції) ще до того, як була спроектована жодна клієнтська фіча. Вісім тижнів зосередженої розробки — онбординг бригади, управління доступністю, прийняття замовлень, GPS-відстеження та адмін-панель диспетчеризації. Ми провели перше реальне замовлення через систему до того, як існував клієнтський застосунок.
React Native для обох застосунків
Одна кодова база, два досвіди. Застосунок для бригади оптимізовано для польового використання — великі цілі для торкання, офлайн-режим, розроблений для спітнілих рук після підйому дивана. Клієнтський застосунок оптимізовано для процесу бронювання, що займає менше трьох хвилин.
Диспетчеризація на основі правил, а не алгоритмів
Ми розглядали матчинг на основі ML і відхилили його. Ринок занадто малий, щоб навчальні дані мали значення. Натомість: близькість, вікна доступності, місткість бригади та відповідність категорій замовлення — детерміновано, перевірювано та налагоджувано о 2 ночі.
Stripe Connect для ескроу
Кошти утримуються при бронюванні, вивільняються бригаді після завершення роботи, повертаються при суперечці. Ніякої готівки, ніякого переслідування рахунків. Платіжний шар також надає дані, що роблять розширення можливим: середня вартість замовлення, пікові години, заробіток бригади.
Два застосунки і движок між ними.
- Онбординг бригади з завантаженням документів і ручним підтвердженням
- Календар доступності в реальному часі з блокуванням та повторюваними слотами
- Push-сповіщення про нові пропозиції замовлень з вікном прийняття 10 хвилин
- Живе GPS-відстеження, що ділиться з клієнтом під час активного замовлення
- Цифровий листок замовлення — чеклист, завантаження фото, підтвердження завершення
- Панель заробітку з розбивкою по кожному замовленню
- Розрахунок вартості від адреси до адреси менш ніж за 60 секунд
- Оцінювач інвентарю переїзду (кімнати, поверхи, важкі предмети)
- Профіль бригади з рейтингами та кількістю виконаних замовлень до бронювання
- Безпечна оплата карткою через Stripe — утримується до підтвердження завершення роботи
- Відстеження бригади в реальному часі у день переїзду
- Двосторонній рейтинг після роботи з підтвердженим відгуком
- Автоматичний матчинг бригад на основі близькості, доступності та місткості
- Виявлення конфліктів — гарантія нульових подвійних бронювань
- Операційний дашборд з живою картою замовлень та статусами бригад
- Панель вирішення суперечок із вкладеними доказами
- Звіти про виручку, продуктивність бригад та теплові карти попиту
- Ручне перевизначення для граничних випадків без залучення інженерів
Я скептично ставився до 16-тижневих термінів — мене вже підводили агентства, що обіцяли швидкість і доставляли відмовки. На 10-му тижні наші бригади вже виконували реальні замовлення через застосунок. На 14-му я закрив свої WhatsApp-групи диспетчеризації. Більше мені нічого не потрібно було знати.
Уроки, що приходять лише від реальної експлуатації.
Перша суперечка вчить більше, ніж перше бронювання
Третій тиждень після запуску: клієнт заявив, що бригада пошкодила меблі. Бригада заперечила. Ми спроектували систему суперечок, але не стрес-тестували граничні випадки. Протягом наступного тижня ми випустили чотири покращення до потоку завантаження доказів та ескалації.
Щільність пропозиції — це все
Маркетплейс зазнає невдачі, коли попит не задоволений. Ми виявили, що деякі райони Праги систематично мають низьке покриття бригадами. Дані теплової карти адміну зробили це видимим — ми використали їх для цільового набору бригад у цих районах.
Час push-сповіщень — це продуктове рішення
Наше перше вікно сповіщень про пропозицію роботи було 5 хвилин. Бригади постійно їх пропускали — вони несуть дивани. Подовження до 10 хвилин із нагадуванням на 7-й хвилині підвищило коефіцієнт прийняття на 40%. Число, яке жоден алгоритм нам не сказав би.
Будуєте маркетплейс?
Ми зробили кожну помилку, щоб вам не довелося — і маємо чергування on-call, щоб це довести. Розкажіть нам про ваш ринок.