Кейс: онлайн-запись для барбершопа за 24 дня. Что пошло не так и как решили

Честный пост-мортем. Без приукрашивания.

Три месяца назад к нам пришёл владелец сети из трёх барбершопов в Москве. Запрос простой: убрать WhatsApp-запись, сделать онлайн-бронирование через сайт и Instagram. Бюджет — 350 000 рублей, срок — 3–4 недели.

Запустились за 24 дня. Но путь был не прямым.

Что хотел клиент (и что он имел в виду)

На первой встрече задача звучала так:

«Хочу кнопку "Записаться" на сайте. Клиент выбирает мастера, время, и сразу видит, когда он свободен. Без звонков, без WhatsApp, без участия администратора».

Мы взяли задачу. Провели аналитику за 3 дня, написали ТЗ. Казалось, всё ясно.

Ошиблись.

Ошибка #1: «Понятный» бизнес-процесс, который оказался непонятным

На третий день разработки выяснилось, что у каждого мастера — своё расписание, которое меняется каждую неделю. Один работает только в первой половине дня, другой — через день, третий берёт выходные не по расписанию, а «когда надо».

В нашем ТЗ был пункт «расписание мастеров», но мы предполагали стандартное: пн–пт, 10:00–20:00. Реальность оказалась сложнее.

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

Потери: 2 дня задержки, 15 000 ₽ доработок сверх бюджета (договорились включить в стоимость).

Урок: для сервисного бизнеса всегда спрашивать: "А как вы управляете расписанием сейчас? Покажите в WhatsApp или Excel".

Ошибка #2: Интеграция с Instagram оказалась невозможной

Клиент хотел кнопку «Записаться» прямо в Instagram. Это звучит логично и просто. На практике — Instagram API не позволяет встраивать внешние формы бронирования в профиль без Business Manager и Meta Pixel, что требует верификации бизнеса.

Мы это знали. Но не уточнили заранее, верифицирован ли аккаунт.

Аккаунт верифицирован не был. Процесс верификации занял 11 дней (вне наших рук).

Что сделали: временное решение — ссылка на страницу записи в bio + Stories с UTM-метками. После верификации — полноценная кнопка.

Потери: нулевые финансово. Но клиент ожидал полный Instagram-интегрейшн в день запуска — его не было.

Урок: интеграции с внешними платформами нужно проверять ещё на этапе продажи. Добавили этот чекпоинт в наш sales-процесс.

Ошибка #3: Мы сделали систему для клиента, а не для мастеров

Запись работала. Клиенты бронировали. Но через неделю после запуска позвонил клиент:

— Мастера в WhatsApp мне жалуются. Говорят, не понимают, как смотреть своё расписание.

Мы сделали личный кабинет мастера в вебе. Красивый, с таблицей записей на неделю. Мастера открывали его раз, не разобрались и закрыли.

Им нужны были уведомления в Telegram: «Завтра в 12:00 — Алексей, стрижка + борода».

Что сделали: добавили Telegram-бота для мастеров. Утром — сводка на день. При новой записи — уведомление. Возможность подтвердить или попросить перенос прямо в чате.

Потери: 3 дня разработки. Это была незапланированная работа, которую мы сделали за свой счёт — потому что считали это частью "работает" продукта.

Урок: реальные пользователи — не всегда те, кто платит. Нужно интервьюировать всех участников системы до начала разработки.

Ошибка #4: Деплой в пятницу вечером

Это классика. Мы знали правило. Нарушили.

Дата запуска была согласована на пятницу — клиент хотел пустить сарафанное радио на выходных. За час до завершения деплоя обнаружили конфликт в nginx-конфиге, который на стейджинге не воспроизводился.

Чинили 40 минут. Запустились в 23:20 вместо 22:00.

Потери: нервы. К счастью, клиент был рядом и видел, как мы это решаем.

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

Итоговые метрики через 30 дней после запуска

Клиент говорит: «Лучшая инвестиция за год. Жалею, что не сделал раньше».

Что сделали правильно

1. Фиксированная цена и срок. Даже когда мы добавляли незапланированные функции, клиент не получал новые счета. Он знал итоговую сумму с первого дня. Это снимает стресс с обеих сторон.

2. Еженедельные демо. Каждую пятницу — 30-минутный звонок с демонстрацией текущего состояния. Так мы поймали ошибку с расписанием на 3-й день, а не на 20-й.

3. Простое техническое решение. Мы могли сделать "умную" систему с ML-предсказанием загруженности и автоматической перезаписью. Сделали простую — бронирование, расписание, уведомления. Это правильно для MVP.

4. Мобильный-first. 87% записей пришли с мобильных. Хорошо, что мы оптимизировали под мобайл с самого начала.

Стек и технические решения

• Backend: FastAPI + PostgreSQL
• Frontend: Next.js (лендинг + форма записи)
• Telegram-бот для мастеров: aiogram
• Деплой: Railway
• Оплата: пока не реализована (клиент собирает предоплату отдельно)
• Срок разработки: 24 рабочих дня

Общая стоимость: 350 000 ₽ + 15 000 ₽ (доработка расписания) = 365 000 ₽.

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

Следующая статья: честный финансовый расчёт — когда нанять разработчика, а когда обратиться в студию. Со скрытыми издержками, которые обычно не считают.