Система закрывает типичный хаос диспетчерской: заявки в мессенджерах и таблицах, потерянные клиенты, путаница «кто едет», ручные переносы и отсутствие общей картины по дням и суммам. Диспетчер работает в браузере, мастер — в Telegram. Один контур, без громоздких Excel-таблиц.
Кому подходит
Небольшой и средний сервис выездных мастеров, где заявки идут потоком, а решение нужно принимать за минуты: принять, отказаться, переназначить, закрыть.
Умное управление заказами
• Рабочий календарь на 3 недели: видно загрузку по дням, а не список «на всю вечность».
• Фильтры: новые, закрытые, нулевая цена и другие статусы.
• Жизненный цикл заявки: новая → назначена → распределена → принята / отказ → выполнена → закрыта. Отдельно: мастер не прибыл, отказ клиента.
• Назначение, перенос между мастерами, удаление, карточка заявки.
• Итоги по сумме и количеству заказов в выбранном периоде.
Координация через Telegram
• Мастер получает карточку заказа: номер, услуга, адрес, дата/время, цена, комментарий.
• Кнопки в чате: «Принять», «Отказаться», «Выполнено».
• Диспетчер сразу видит отказ или выполнение — без звонков «ну что там?».
• Бот работает в личке и в групповых чатах. Привязка Telegram к профилю мастера — через авторизацию, а не «кто первый написал боту».
• Команда /orders показывает активные заявки мастера.
База клиентов и адресов
Профили с телефоном, адресом и историей обращений. Город и улица собираются в полный адрес автоматически. Повторный вызов не начинается с пустой карточки.
Управление мастерами
Профиль: ФИО, специализация (сантехника / электрика / быт / уборка), города, доступность, дата приёма, Telegram ID.
Роли и права: диспетчер, мастер, админ. Можно отключить доступ или отметить увольнение — заявка не уйдёт «не туда».
Документы, история, аналитика
К заявке крепятся чеки, акты, отзывы.
Фиксируется, кто создал и кто менял карточку.
Есть журнал переназначений мастеров.
На дашборде — суммы, количество заказов, фильтры по календарю.
Как устроено технически
Веб-кабинет на платформе с документной моделью данных и TypeScript-логикой дашборда (календарь, грид, фильтры, кнопки действий).
Серверная часть Telegram — webhook на C# (ASHX): разбор update, callback-кнопки, смена статусов, уведомления диспетчеру, отправка карточек в личку и группы.
Почему это удобно в работе
• Браузер + полноценный Telegram-бот, без установки приложения мастеру.
• Интерфейс заточен под поток заявок, а не под «универсальную CRM на все случаи».
• Сотрудника можно посадить за календарь за короткое время: статусы и кнопки читаются без инструкции на 20 страниц.
Результат
Диспетчер видит день и неделю целиком. Мастер отвечает по кнопке. Клиент не теряется между чатами. По каждой заявке понятно: кто назначен, что сделано, чем закрыто и сколько это стоило.
Готов показать демо, адаптировать статусы, роли и карточки под ваш регламент.
Задача. Собрать рабочую CRM под выездной бытовой сервис: диспетчер ведёт поток заявок в одном окне, мастер отвечает с телефона, статусы и деньги не расходятся, клиенты и исполнители не теряются в переписке.
1. Разобрал процесс, а не «набор экранов».
Сначала зафиксировал цепочку: заявка пришла → назначен мастер → мастер принял или отказался → выехал / не выехал → работа сделана → закрыто и оплачено. Отдельно вынес отказ клиента и «мастер не прибыл»: это разные причины и разная аналитика. По этим статусам построена вся логика кабинета и бота.
2. Спроектировал доменную модель.
Выделил сущности: заявка (OrderService), клиент, пользователь (мастер / диспетчер), адрес / город, вложения, журнал переноса между мастерами.
У заявки: тип услуги, дата поступления и дата/время выезда, цена, телефон, адрес, описание, ответственный логист, мастер, статус, вложения, признак полного закрытия.
У мастера: специализации, города, доступность, роли, Telegram ID, флаг увольнения.
У вложений — тип: чек, акт, отзыв.
Так система перестала быть «таблицей заявок» и стала контуром учёта.
3. Собрал диспетчерский дашборд.
Вместо бесконечного списка сделал календарь на 3 недели + грид заявок.
Написал клиентскую логику на TypeScript: фильтрация по статусам и датам, пересчёт грида из календаря, счётчики по дням, итоги по сумме и количеству, кнопки «назначить / перенести / детали / обновить / удалить».
Календарь и таблица связаны: клик по дню сужает список, фильтры не ломают картину загрузки.
4. Закрыл назначение и переназначение.
Первичное назначение мастера и последующий перевод — разные сценарии. Для перевода завёл отдельный журнал, чтобы было видно, кто ушёл с заявки и кто её принял. Это убирает спор «я эту заявку не брал».
5. Вынес работу мастера в Telegram.
Написал webhook на C#: приём update, авторизация мастера (привязка chat_id к профилю, а не к случайному номеру), команда /orders, сборка карточки заказа, inline-клавиатура.
Кнопки «Принять / Отказаться / Выполнено» меняют статус заявки в той же базе, что и веб-кабинет. Отказ уходит диспетчеру уведомлением.
Бот умеет писать в личку и в группу — это нужно бригадам, которые живут в общем чате.
6. Настроил роли и безопасность доступа.
Разделил права диспетчера и мастера. Мастер не видит чужой поток. Недоступного или уволенного сотрудника система не предлагает как исполнителя. Привязка Telegram требует подтверждения, чтобы чужой чат не перехватил заявки.
7. Добавил документы и след изменений.
К заявке крепятся файлы с типом. У карточек есть автор создания и автор последнего изменения. Диспетчер может восстановить картину: кто назначил, кто перенёс, чем закрыли вызов.
8. Собрал контур «всё в одном окне».
Веб — планирование и контроль. Telegram — реакция в поле. Общая модель статусов, чтобы кабинет и бот не жили в разных реальностях.
Обучение сведено к календарю, статусам и трём кнопкам в чате.
Итог работы
Получился не конструктор «ещё одной универсальной CRM», а прикладной контур диспетчерской бытовых услуг: заявка не теряется, мастер отвечает с телефона, диспетчер видит день и деньги, по каждому вызову есть статус, исполнитель и документы.
Получилась рабочая CRM под выездной бытовой сервис, а не «ещё одна таблица с статусами». Заявка, мастер, клиент, адрес, документы и Telegram связаны в один контур: что видит диспетчер в браузере, то же самое подтверждает мастер кнопкой в чате.
Что есть на выходе
• Диспетчерская в браузере: календарь на 3 недели, фильтры, карточка заявки, назначение и перенос мастера, итоги по сумме и количеству.
• Полноценный Telegram-бот: карточка заказа, кнопки «Принять / Отказаться / Выполнено», уведомление диспетчеру, список активных заявок по /orders, работа в личке и в группе.
• Справочники клиентов, мастеров и городов. У мастера — специализация, города, доступность, роли, Telegram ID.
• Документы по заявке (чек, акт, отзыв) и след изменений: кто создал, кто правил, кого переназначили.
• Понятный жизненный цикл: новая → назначена → распределена → принята / отказ → выполнена → закрыта. Отдельно фиксируются «мастер не прибыл» и отказ клиента.
Как это применяют на практике
Диспетчер / логист.
Утром открывает календарь, а не переписку в трёх чатах. Видит, какие адреса на сегодня и на ближайшие недели, где дыры в загрузке, какие заявки ещё без мастера или с нулевой ценой. Новую заявку заводит в карточке: услуга, адрес, время, цена, комментарий — и назначает исполнителя. Если мастер отказался, система сама сообщает об этом, заявку можно перекинуть другому. Не нужно выяснять статус звонком «ну что там».
Мастер в поле.
Не ставит отдельное приложение и не лезет в веб-кабинет с телефона. В Telegram приходит карточка: куда ехать, что делать, к какому часу, почём работа. Одной кнопкой принимает, отказывается или закрывает вызов. Команда /orders показывает только его активные заявки. Бригада может вести тот же поток в групповом чате.
Руководитель сервиса.
В одном окне видно объём и деньги за период, а не «как получилось в таблице». Понятно, кто из мастеров доступен, кто уволен, кому какие города и услуги. По закрытой заявке остаются акт, чек или отзыв — спор «сделали / не сделали / не заплатили» разбирается по карточке, а не по памяти.
Клиентский контур.
Повторный вызов не начинается с нуля: телефон, адрес и история уже в базе. Диспетчер не теряет человека между WhatsApp, блокнотом и чужой памятью смены.
Как будут пользоваться дальше
Систему можно сразу ставить на поток небольшого и среднего сервиса: сантехника, электрика, уборка, мелкий ремонт. Типовой день выглядит так: заявка попадает в кабинет → диспетчер назначает мастера по услуге и городу → мастер отвечает в Telegram → статус и сумма обновляются в той же заявке → документы крепятся к карточке → период закрывается по календарю.
При масштабировании не нужно менять идею продукта: добавляются мастера, города и роли, календарь и бот остаются рабочим местом. Статусы, поля карточки и тексты уведомлений можно подогнать под регламент конкретной диспетчерской — контур при этом тот же.
Итог
Хаос «чат + таблица + звонок» заменяется одним правилом: заявка живёт в MasterOK от поступления до закрытия. Диспетчер планирует, мастер подтверждает с телефона, по каждому вызову есть исполнитель, статус, сумма и документы.
