Веб-приложение для доставки воды: подписки и маршруты

С чего начинается сервис доставки воды и где чаще ломается

Доставка воды держится не на разовых заказах, а на повторяемости. Клиенты ждут воду по привычному графику, и сбои чаще всего возникают там, где этот график меняется: переносы, пропуски, паузы, смена адреса, замена контактного лица.

Обычно ломается простая цепочка: оператор пообещал, курьер не увидел, клиент ждал, а к вечеру никто не понимает, где случилась ошибка. Типичные симптомы: пропуски "потому что не заметили", переносы "потому что записали в чат", забытые подъезды и домофоны, маршруты собираются вручную и каждый раз по-разному.

В сервисе почти всегда есть три роли, и у каждой своя "правда":

• Оператор фиксирует изменения и отвечает клиенту "когда привезем".
• Курьер видит точки на сегодня и статусы доставок.
• Клиент чаще пишет в мессенджер или звонит и ждет короткий, понятный ответ.

Для первого релиза не нужно пытаться охватить все. Минимум, который реально наводит порядок, это единый реестр клиентов и календарь поставок с понятными статусами. Маршрутизация может быть простой, но должна быть привязана к конкретным доставкам на конкретный день.

Данные, которые стоит хранить сразу, чтобы не упереться через месяц: клиент (ФИО или компания, телефон), список адресов (с пометками домофон, этаж, время), подписка (периодичность, объем, предпочтения), отдельные поставки (дата, адрес на эту поставку, окно времени) и статус (запланировано, перенесено, пропущено, выполнено, не удалось).

Небольшой пример: клиент "Ирина, офис" получает 2 бутыли по понедельникам. В четверг она просит доставить на другой адрес только на следующую неделю. Если вы храните только "адрес клиента", курьер в понедельник уедет не туда. Если адрес задается на уровне конкретной поставки, ошибка не случится.

Когда этот каркас понятен, веб-приложение для доставки воды проще всего собирать по шагам: сначала роли и статусы, потом таблицы реестра и календаря, и уже после этого - планировщик маршрутов.

Модель подписки и графика поставок простыми словами

Подписка в доставке воды - это правило, по которому клиент получает воду регулярно. В ней фиксируются периодичность (например, раз в неделю), объем (2 бутыли по 19 л), удобные дни (вторник и пятница) и временное окно (например, 9:00-12:00). Это не конкретный заказ на дату, а шаблон, из которого потом появляются поставки.

Ключевое правило: разделяйте подписку и поставку (заказ на дату). Подписка отвечает на вопрос "как обычно?". Поставка отвечает на вопрос "что именно везем 23 января и куда?". Если смешать эти понятия, начнутся типовые ошибки: перенос одной доставки внезапно меняет весь график, а смена адреса "на один раз" превращается в "навсегда".

График поставок удобно хранить как список будущих дат, созданных на основе подписки (например, на 4-8 недель вперед). Тогда диспетчер видит реальную картину, может переносить отдельные доставки и не ломает правило подписки.

Чтобы всем было понятно, держите короткие статусы подписки:

• активна
• на паузе
• отменена
• просрочена (например, нужна оплата или не подтвержден следующий период)
• требует подтверждения (после смены условий или долгого перерыва)

Операции должны быть "безопасными": перенос даты меняет только одну поставку, пропуск отменяет одну поставку, но не трогает остальной график. А смена адреса должна явно иметь режим: "только на эту доставку" или "для всех будущих". Такая модель без конфликтов ложится в веб-приложение для доставки воды и потом не мешает ни маршрутам, ни учету.

Пример: у Ольги подписка по средам. На следующей неделе она уезжает - диспетчер ставит паузу на 10 дней, и поставки на этот период не появляются. А если Ольга просит перенести ближайшую доставку с 24 на 25 число, меняется только один заказ на дату, без переписывания подписки.

Правила паузы, пропуска и переноса доставок

Чтобы подписки не превращались в ручной хаос, выделите три отдельные операции: пауза (остановить подписку), пропуск (пропустить одну поставку) и перенос (сдвинуть конкретную поставку). Тогда оператор всегда выбирает понятное действие, а система ведет себя предсказуемо.

Пауза подписки

Пауза действует с указанной даты (и, при желании, с времени). Важно заранее решить, что делать с уже созданными поставками в будущем. Практичный вариант: все поставки с даты паузы помечаются как "отменены из-за паузы", но остаются в истории.

Возобновление лучше поддержать двумя способами: "с даты" (продолжить по обычному шаблону) или "со следующей возможной доставки" (если пропущен целый период). При возобновлении система заново создает будущие поставки по графику, не трогая фактически выполненные.

Пропуск одной доставки

Пропуск не останавливает подписку. Он применяется к конкретной дате в календаре поставок и фиксирует причину (клиент уехал, нет тары, ремонт в офисе). Пропущенная поставка остается в расписании как запись со статусом "пропуск", чтобы курьер и диспетчер не спорили, была она или нет.

Перенос доставки

Перенос относится к конкретной поставке и меняет дату (иногда и временное окно). Полезно поддержать два режима: перенос на ближайшую доступную дату или на выбранную вручную. Ограничения задайте заранее: например, перенос не может увести доставку на дату раньше текущего дня и не должен пересекаться с уже существующей доставкой в тот же адрес и интервал.

Чтобы не обещать лишнего, введите дедлайны изменений:

• перенос и пропуск возможны до 20:00 накануне
• пауза "с завтра" возможна до 18:00 сегодня
• в день доставки изменения разрешены только оператору с причиной и комментарием

Отдельно продумайте историю: кто изменил, когда, что было "до" и "после", и почему. Это удобно хранить как журнал событий (пауза, возобновление, пропуск, перенос) и показывать в карточке клиента и в поставке. Если собираете это через чат, сразу закладывайте статусы и журнал действий - иначе потом будет трудно разбирать спорные случаи.

Смена адреса: один раз или навсегда и как не запутаться

Адреса - место, где подписки чаще всего начинают путаться. У одного клиента может быть дом, офис, дача и еще разовый адрес (например, для подарка). Поэтому удобно хранить у клиента один основной адрес и несколько дополнительных, а каждую конкретную доставку привязывать к выбранному адресу.

Один раз (на поставку) или навсегда (для подписки)

Разделите два действия, которые звучат одинаково для клиента: "перенесите мне на другой адрес".

• Вариант 1: смена адреса только у одной поставки.
• Вариант 2: смена адреса по умолчанию для всей подписки с определенной даты.

Практичное правило: если клиент говорит "только в этот раз" - меняем адрес у конкретной доставки. Если говорит "теперь всегда сюда" - меняем основной адрес подписки, но не трогаем уже выполненные доставки и не переписываем историю.

Чтобы оператор не ошибся, в интерфейсе лучше показывать два переключателя: "Изменить только эту доставку" и "Изменить адрес подписки". Рядом - короткое пояснение, что будет с будущими датами.

Проверка зоны доставки и деталей подъезда

Адрес - это не только улица и дом. В карточке адреса храните поля, которые реально нужны в день доставки: район или зона доставки (для расчета цены и доступных дней), подъезд, этаж, код домофона, наличие лифта и комментарий для курьера. Если контакт на месте отличается от владельца подписки, это тоже лучше фиксировать прямо в адресе.

После смены адреса сразу проверяйте зону: обслуживается ли район, подходит ли день и временное окно, не изменится ли стоимость. Если зона другая, лучше предложить ближайший доступный слот, чем "оставить как было".

Если вы делаете веб-приложение для доставки воды, заведите простое правило валидации: адрес можно сохранить, только если выбранная зона доставки активна.

Если адрес изменился в день доставки

В день доставки важны скорость и единая версия правды. Рабочий сценарий такой: оператор меняет адрес у конкретной доставки, система фиксирует время и автора изменения, курьер получает обновление и подтверждает, что увидел его.

Пример: клиент в 9:30 пишет, что сегодня будет в офисе, а не дома. Оператор открывает доставку на сегодня, выбирает "изменить только эту доставку", ставит адрес "Офис" и добавляет комментарий "вход со двора". Курьер видит обновление до выезда и не едет по старому адресу.

Реестр клиентов: что хранить в карточке и как искать

Реестр клиентов - это ваша "память": кому, куда и на каких условиях вы возите воду. Если он неудобный, операторы начинают вести заметки в мессенджерах, а курьеры ездят "по привычке", и ошибки быстро копятся. В хорошем реестре человек находится за 10 секунд, и сразу видно, что будет дальше по графику.

Что хранить в карточке клиента

Начните с простого, но достаточного набора. Важно не только "как связаться", но и то, что влияет на доставку:

• Контакты: ФИО или название, телефон, запасной телефон, комментарий "как дозвониться".
• Адреса: основной адрес, подъезд/этаж/домофон, альтернативные адреса (офис, дача).
• Подписки: активна/пауза, частота, тип воды или тары, типичное время, пожелания к курьеру.
• Финансы: способ оплаты, статус (оплачено/долг/переплата), лимит по долгам (если используете).
• История: последние доставки (успешно/отказ/перенос), возвраты тары, заметки оператора.

Отдельное поле "источник" (рекомендация, реклама, повторный клиент) помогает понять, откуда реально приходят заказы.

Как искать и фильтровать, чтобы не тонуть

Один хороший фильтр заменяет десяток уточнений по телефону. Обычно полезны срезы по району или улице, по статусу подписки, по ближайшей доставке (сегодня/завтра), а также "есть долг" или "переплата".

По ролям часто достаточно двух уровней доступа:

• Оператор видит все поля, меняет адреса, подписки, платежный статус, добавляет заметки.
• Курьер видит маршрут на день, адрес, контакт, комментарии для подъезда и отметку "оплачено/принять оплату", без лишних данных.

Календарь поставок: как формировать и редактировать график

Календарь поставок - экран, где видно работу сервиса по дням: сколько доставок запланировано, в какие окна времени и по каким районам они распределены. Для диспетчера это главный инструмент: он думает не "по подпискам", а "что едет завтра утром и кто это повезет".

Чтобы календарь был полезным, в каждой доставке держите минимум полей: дата и временное окно, клиент и адрес (с привязкой к району), состав заказа (количество бутылей, тара, доптовары), статус (запланировано, подтверждено, выполнено, отменено) и комментарий для курьера.

Автогенерация обычно строится "из подписок на неделю вперед". Раз в день (или по кнопке) система берет активные подписки, применяет правила паузы, пропуска и переноса и создает конкретные доставки на ближайшие 7 дней. Важно: после генерации подписка не исчезает, меняется только календарь. Так проще править реальный план, не ломая базовые условия клиента.

Ручные правки неизбежны, поэтому нужны быстрые действия прямо в календаре: добавить разовую доставку, отменить одну доставку, перенести на другой день или окно, дописать комментарий. Хорошая практика - сохранять причину ("клиент уехал", "не дозвонились") и автора изменения. Эти мелочи потом экономят часы разборов.

Контроль конфликтов нужен сразу, даже в первой версии:

• две доставки на один адрес в одном окне (часто это дубль)
• две доставки на одного клиента в один день (если это запрещено правилами)
• перегруз окна по времени (условно 40 остановок в 3 часа)
• адрес без района (его сложно маршрутизировать)

Пример: в среду у клиента Петрова подписка на утро, но он просит перенести на пятницу вечер. Диспетчер открывает доставку в календаре, меняет дату и окно, добавляет комментарий "после 18:00". Система показывает предупреждение: в пятницу вечер уже есть доставка на тот же адрес. Дальше диспетчер решает - объединить в одну поставку или оставить две.

Планировщик маршрутов: минимальная логика, которая работает

Планировщик маршрутов курьеров не обязан сразу искать "идеальный" путь. На старте важнее, чтобы диспетчер быстро собирал понятный маршрут, а курьер мог ехать без сюрпризов. Практичный минимум: разбить заказы по районам, учесть ограничения (время, вместимость, склад), а затем выстроить простой порядок точек.

Какие данные нужны

Чтобы построение было предсказуемым, заранее договоритесь, что считается "правдой" в данных:

• адрес и геоточка (координаты)
• окно времени
• длительность остановки (например, 7 минут на передачу и оплату)
• старт и финиш (склад или база)
• ограничения по машине: вместимость и время смены

Дальше цель простая: распределить точки по зонам (район, микрорайон, "левый берег/правый берег"), а внутри зоны упорядочить по близости и по окнам времени. Уже это дает заметный эффект без сложной математики.

Выход маршрута и правки

Хороший результат маршрута - не обязательно карта, а четкий план действий: список остановок по порядку, комментарии (домофон, "оставить у охраны", "нужна сдача"), плюс суммарный план по времени: выезд со склада, ожидания, ориентировочное прибытие к каждому адресу.

Пример: утром 18 доставок. Вы делите их на 2 района и 2 машины, проверяете, что каждая машина по вместимости проходит (например, 12 и 14 бутылей), и получаете два списка остановок с расчетом времени в пути и по 7 минут на точку.

Изменения после построения неизбежны: перенос, новая заявка, отмена. Минимальная логика такая: маршрут "замораживается" после выезда, а новые точки добавляются как вставка в ближайшее подходящее место, где не ломаются окно времени и вместимость. Если не помещается, заявка уходит в "хвост" или на другую машину, а диспетчер видит причину.

Пример из жизни: неделя доставок с паузами и переносами

Понедельник, у вас 30 клиентов, и веб-приложение для доставки воды уже ведет подписки. Из них 6 клиентов поставили неделю на паузу (ничего не везем и не списываем), 3 попросили пропуск одной доставки (подписка активна, но конкретный визит не едет), еще у двоих - перенос: один со среды на четверг, второй с пятницы на субботу. И вдобавок один клиент в понедельник в 8:40 меняет адрес доставки на сегодня.

Оператор открывает календарь поставок и правит все точечно, не ломая весь график. Важный принцип - меняется не подписка целиком, а конкретные доставки:

• пауза: все доставки в периоде получают статус "отменено по паузе", следующий плановый визит сдвигается на дату после паузы
• пропуск: у конкретной даты статус "пропуск", следующая дата остается как была
• перенос: у исходной даты статус "перенесено", создается новая доставка на нужный день
• смена адреса "на сегодня": адрес меняется только у одной доставки, подписка и "постоянный" адрес не трогаются

После этого оператор нажимает "пересобрать маршрут" на день. Если утром поменяли адрес, система просто пересчитает остановки для одного курьера: точка переместится, а остальные 29 клиентов останутся на местах.

Курьер видит задание списком остановок с окнами времени, адресом, количеством бутылей и комментарием (например, "код домофона"). По каждой остановке он отмечает результат: доставлено, закрыто (никого нет дома), не дозвонились, перенос по инициативе клиента, отказ.

Если "закрыто" или "не дозвонились", оператору приходит причина, и он решает: перенести на завтра или оформить пропуск. На следующую неделю это влияет предсказуемо: перенос добавляет дополнительную доставку, пропуск уменьшает количество визитов, пауза сдвигает график. А "недоставку" можно автоматически предлагать перенести, чтобы подписка не расползалась по датам.

Типичные ошибки при запуске и как их избежать

Частая причина провала в том, что команда пытается сделать идеальный сервис сразу. Для первого релиза веб-приложение для доставки воды должно уверенно закрывать базовые вопросы: кто, куда, когда и сколько, плюс простые правки без путаницы.

Ошибки, которые почти всегда всплывают в первые недели, и что делать вместо этого:

• Слишком много статусов и исключений. Вместо 15 состояний оставьте 4-5: активна, пауза, пропуск (на конкретную дату), отмена заказа, выполнено. Остальное добавите, когда появятся реальные кейсы.
• Нет истории изменений. В итоге никто не понимает, почему доставка исчезла или переехала. Нужен журнал: что изменили, старое и новое значение, кто и когда. Даже запись "перенос с 12 на 13" уже спасает.
• Смешивание подписки и поставки. Клиент просит перенести одну доставку, а менеджер случайно двигает всю подписку. Правило простое: подписка хранит шаблон (дни недели, объем), а поставка - конкретную дату. Перенос делается у поставки.
• Нет дедлайнов на изменения. Если можно править в любое время, начинается хаос утром в день доставки. Введите крайние сроки: например, изменения на завтра принимаются до 18:00 сегодня, на сегодня - только по телефону и с отметкой причины.
• Маршрут строится без времени на подъезд и разгрузку. Тогда план на бумаге красивый, но курьер опаздывает на каждом адресе.

Для маршрутов полезно зафиксировать простые нормы и не спорить с ними каждый день:

• среднее время на адрес (подъем, обмен тары): 5-10 минут
• окно доставки для клиента: хотя бы 2-3 часа
• резерв на пробки и поиск парковки: 10-15% от времени маршрута

Практичный подход для старта: собрать минимальную версию в режиме планирования, добавлять правила по фактам и держать возможность отката, чтобы не бояться массовых правок.

Короткий чеклист перед тем, как выпускать в работу

Перед запуском важнее всего проверить не "красоту интерфейса", а то, что данные не разваливаются в реальных ситуациях. Лучше потратить один день на проверки, чем потом вручную разруливать десятки звонков и переносов.

Начните с самой маленькой единицы системы - поставки. Откройте 10-20 поставок из разных сценариев (обычная, после переноса, после смены адреса, после паузы) и убедитесь, что карточка читается одним взглядом.

Проверьте базовый минимум:

• у каждой поставки заполнены дата, адрес, объем (или количество бутылей), временное окно и статус (запланирована/подтверждена/в пути/доставлена/неудачно)
• пауза подписки не ломает уже подтвержденные поставки: видно, что остается "как было", а что отменяется или не создается на будущие даты
• перенос доставки фиксирует причину и пользователя, кто сделал изменение (оператор, клиент через личный кабинет, менеджер)
• маршрут всегда стартует от склада и показывает понятный порядок точек (даже если он пока простой)
• курьер может отметить результат доставки и оставить комментарий (например, "не дозвонились", "перенесли на завтра", "оставили у охраны")

Затем проверьте связку "реестр клиентов - календарь - маршрут". Быстрый тест: возьмите одного клиента, сделайте паузу на неделю, перенесите одну доставку на другой день и смените адрес на один раз. После этого откройте календарь поставок и маршрут курьера на нужную дату: изменения должны отразиться ровно там, где вы ожидаете, без дублей и пропаж.

Следующие шаги: собрать первую версию через чат и протестировать

Быстрее всего перейти от идеи к работающему сервису помогает короткий, понятный список требований. Он нужен не "для отчета", а чтобы команда одинаково понимала, что считать готовым.

Соберите требования в одном месте: какие сущности есть в системе (клиент, адрес, подписка, поставка, перенос), какие у них статусы (активна, на паузе, пропущена, перенесена), какие дедлайны важны (до какого времени можно менять доставку на завтра) и кто что делает (оператор, логист, курьер, админ).

Дальше разумно собрать прототип через чат, чтобы сразу увидеть скелет продукта. В TakProsto это удобно делать итерациями: описываете поведение словами, затем уточняете детали на примерах.

Практичный порядок, который обычно дает результат за 1-2 дня:

• сделайте реестр клиентов: поиск, карточка клиента, адреса (основной и временный), заметки
• добавьте календарь поставок: просмотр по дням, ручная правка, отметки "пауза/пропуск/перенос"
• сформируйте маршрутный лист: список точек на день, комментарии для курьера, отметки "доставлено/не доставлено"
• включите защиту от ошибок: снимки состояния и откат, чтобы спокойно проверять массовые правки
• подготовьте пилот: роли и доступы, развертывание, а когда команда готова - подключение домена

Тестируйте не "в целом", а на жизненном сценарии. Например: клиент перенес доставку с четверга на субботу, в пятницу поставил паузу на 2 недели, а потом сменил адрес только на одну доставку. Если после этого календарь, реестр и маршрутный лист показывают одно и то же, вы близки к рабочей версии.

Если вы собираете такую систему на TakProsto, удобно начинать с режима планирования, а позже при необходимости выгрузить исходный код и продолжить развитие в своем темпе. Платформа доступна на takprosto.ai.