Две оценки сервиса онлайн-записи могут различаться в несколько раз, хотя обе обещают календарь, выбор услуги и кнопку подтверждения. В одном случае клиент занимает час одного специалиста. В другом — одновременно резервирует мастера, помещение и оборудование, вносит предоплату и может переносить часть заказа.
Поэтому содержательный ответ на вопрос о стоимости начинается с правил записи. Универсальной цены без границ проекта нет. Но заказчик может подготовить состав работ так, чтобы сравнивать предложения и видеть, какая особенность действительно увеличивает объём разработки.
Зафиксируйте результат одной записи
Опишите, что получает клиент после подтверждения: услугу определённой длительности, специалиста, место, набор ресурсов и понятные условия изменения. Выбранное время должно соответствовать доступности всех обязательных участников.
Начните с одной услуги. Запишите её продолжительность, подготовку до и после, допустимых исполнителей и необходимые ресурсы. Если длительность зависит от параметров заказа, укажите, когда она становится известна.
Например, диагностика одного устройства занимает 60 минут, двух — 90. Можно либо спрашивать количество до показа времени, либо принимать предварительную заявку на уточнение. Нельзя уверенно подтверждать часовой интервал, а длительность выяснять уже после оплаты.
Пример: мастерская с двумя рабочими местами
Рассмотрим условную мастерскую, не кейс ExtentLab. В ней работают два мастера, есть один диагностический стенд и два обычных рабочих места. Услуга занимает 60 минут, после неё стенд готовят ещё 15 минут.
Мастер А свободен с 10:00 до 12:00, мастер Б — с 10:30. Стенд занят до 10:30. Поэтому начало в 10:00 недоступно, хотя мастер А свободен. Ближайший вариант при указанных условиях — 10:30: работа заканчивается в 11:30, подготовка стенда — в 11:45.
Следующая запись на тот же стенд возможна с 11:45, если подходящий мастер свободен на весь требуемый интервал. Подготовку не следует автоматически занимать у мастера, если её выполняет другой сотрудник. Это отдельное правило ресурса.
Такой пример раскрывает больше требований, чем макет календаря. Он показывает, что именно резервируется и какие ограничения должны проверяться одновременно.
Из чего складывается объём проекта
Разделите оценку на самостоятельные блоки. Для каждого перечислите обязательное поведение и то, что пока исключено.
- Каталог услуг: длительность, параметры и подходящие исполнители.
- Расписание: смены, перерывы, отсутствия, занятость ресурсов.
- Запись: выбор времени, контакт, подтверждение и защита от пересечений.
- Изменения: отмена, перенос, неявка и действия администратора.
- Оплата: создание попытки, получение результата, возврат по принятому порядку.
- Уведомления: события отправки, получатели и обработка недоставки.
- Управление: права сотрудников, история изменений и рабочая очередь.
- Проверка и запуск: сценарии, перенос исходных данных и инструкции.
Дизайн и разработка — не весь проект. Наполнение справочников, согласование правил и участие администратора в проверках тоже требуют времени, хотя выполняться могут командой заказчика.
Как читать предварительную оценку
Попросите указать по каждому блоку диапазон трудозатрат, допущения и зависимости. Отдельно перечислите разовые работы и регулярные расходы. Сообщения, платёжное обслуживание, размещение и поддержка не должны незаметно смешиваться с созданием первой версии.
Для иллюстрации возьмём вымышленную оценку: подготовка сценариев — 24 часа, интерфейсы — 40, правила расписания — 64, оплата и уведомления — 32, проверки и выпуск — 40. Всего 200 часов. При условной единой ставке 3 000 рублей получится 600 000 рублей.
Это арифметический пример, не прайс ExtentLab и не ориентир рынка. Он полезен тем, что позволяет обсудить состав: например, что именно включено в 64 часа расписания. Налоговую базу, внешние расходы и порядок изменения оценки нужно указать явно.
Если другой подрядчик назвал 120 часов, сначала сравните сценарии. Возможно, его решение предполагает один ресурс, готовый интерфейс и отсутствие предоплаты.
Предоплата добавляет состояния
Нажатие кнопки оплаты ещё не означает её успешного завершения. Сервис должен различать ожидание, подтверждённый результат, неуспешную попытку и неизвестный исход. Статус записи и статус платежа связаны, но не заменяют друг друга.
На время оплаты место можно удерживать по согласованному правилу. Определите продолжительность удержания и действия при задержке ответа. Если место уже освобождено, позднее подтверждение платежа нельзя молча превратить в запись поверх другого клиента.
Первой версии нужен понятный маршрут такого исключения: администратор видит оплаченный запрос без подтверждённого времени и связывается с клиентом. Возможность автоматического возврата, сроки и порядок зависят от выбранного решения и правил бизнеса; их оценивают отдельно.
Перенос — это изменение двух интервалов
Клиент хочет перенести запись с 10:30 на 15:00. Сначала проверяется новый интервал. Пока перенос не подтверждён, старый не должен случайно исчезнуть. После успешного изменения сотрудники и клиент должны видеть одно актуальное время.
Если новый вариант дороже, запишите порядок доплаты. Если дешевле — порядок корректировки. Система не может выбрать его за владельца бизнеса. Нельзя ограничиться изменением числа в календаре, оставив оплату и уведомления со старыми данными.
Для отмены также задайте последствия: освобождение ресурсов, фиксация причины, дальнейшая работа с оплатой и сообщения участникам. Фактическая неявка отличается от предварительной отмены и должна отмечаться отдельным событием.
Когда стоит выбрать готовое решение
Готовый сервис разумно проверять первым, если услуги имеют стандартную длительность, специалист работает по одному календарю, а переносы и предоплата укладываются в имеющиеся настройки.
Потребность в заказной разработке стоит обсуждать, когда одновременно требуются разные ресурсы, сложные зависимости длительности, нестандартная последовательность подтверждений или обмен с внутренними системами. Но и здесь иногда достаточно отдельного модуля рядом с готовым календарём.
Проведите один и тот же учебный пример в нескольких вариантах. Уточните возможность выгрузки записей, переноса справочников и изменения правил. Выбирайте по важным ограничениям процесса и совокупным расходам, а не только по цене первоначального подключения.
Как ограничить первую версию
Для начала выберите одну площадку, несколько услуг с определённой длительностью, один понятный способ подтверждения и ограниченный набор ресурсов. Предусмотрите рабочее место администратора для исключений.
Автоматическую очередь ожидания, сложные пакеты услуг и распределение между филиалами можно добавить позже, если они не являются основной причиной проекта. Но проверки одновременной записи и корректной отмены должны присутствовать с первого запуска.
Проверяйте ситуации с двумя клиентами на последнее время, отсутствием мастера, закрытием помещения, повторным платёжным уведомлением и переносом во время работы администратора. Для каждой заранее сформулируйте ожидаемый результат.
Что отправить для оценки
Подготовьте список услуг, расписание одной недели, перечень ресурсов и пять сложных ситуаций. Приложите правила предоплаты и отмен, описание действующих систем и список участников, которые будут принимать решения.
После этого предложения можно сопоставлять по составу работ. Поможет разбор сравнения предложений на разработку. В ExtentLab можно обсудить такой набор и определить, какие функции нужны сразу, где подходит готовый сервис и какие неизвестные мешают дать обоснованную оценку.