Domínio Visual — не стартап. Это компания по визуальной рекламе: объёмные буквы, фасады, панели, внутренняя навигация. Клиенты требуют монтаж к конкретной дате, а не к гипотетическому спринту.
Разговор пойдёт о том, что происходит, когда реальный сервисный бизнес решает отказаться от Excel-таблиц, записных книжек и переписок в WhatsApp и переходит на цифровую платформу под себя. Что он получает, что теряет и что почти всегда идёт не так с первой попытки.
Коротко о сути
У сервисного бизнеса три хронические операционные боли: реальное состояние каждого заказа размазано по нескольким головам, история клиента живёт в переписках, а выставление счетов зависит от того, кто вспомнил, что было сделано. Универсальный софт тут ничего не лечит, потому что говорит на чужом языке. Решение — платформа, построенная вокруг реального процесса компании, со статусами, которые соответствуют физическим фазам работы, и интерфейсом, который любой сотрудник освоит без обучения.
В случае Domínio Visual это означало десять статусов — от «техническая выездная» до «выставление счёта», базу MariaDB, спроектированную вокруг заказов, и фронтенд, рассчитанный на человека, который сейчас стоит на объекте, а не изучает дашборд с метриками.
Бизнес-проблема
Компания по вывескам работает проектами. Каждый заказ проходит через несколько физических этапов: кто-то выезжает замерить, кто-то рисует макет, макет уходит на согласование клиенту, печатается или режется материал, собирается металлокаркас для фасада, идёт сборка в цеху, назначается монтаж, вывоз на объект, установка — и только потом счёт.
На каждом этапе работают разные люди. Менеджер, который был на замере, — не дизайнер, рисующий макет. Дизайнер не управляет режущим плоттером. Монтажник на объекте почти никогда не работал в цеху. А клиент звонит и спрашивает «ну что там с моим заказом?» любому из них.
Без платформы ответ зависит от того, кто взял трубку. У каждого — свой кусок пазла. Единой картины не существует нигде: она распределена.
Почему это важнее, чем кажется
В такой модели прячутся три издержки, и все три съедают маржу, не попадая в отчёт о прибыли.
Первая — координация. Каждый заказ порождает десять-двадцать мелких уточнений в WhatsApp. Умножь на тридцать-сорок параллельных работ, и получишь несколько часов в день, когда квалифицированные люди выполняют работу системы.
Вторая — переделки. Без единой истории часто приходится переделывать: утверждённая версия макета похоронена в письме трёхнедельной давности, а замер был записан карандашом, и теперь никто не разбирает почерк.
Третья, самая дорогая, — упущенные счета. Работы смонтированы, но так и не выставлены, потому что выпали из поля зрения. Допработы, оговорённые устно, не дошли до финальной сметы. Исследование Aberdeen Group несколько лет назад показывало, что компании без структурированных цифровых процессов теряли 1–3% годовой выручки на невыставленных или несобранных счетах. Эта цифра нигде не светится — она просто исчезает.
Что значит «цифровая платформа» для такого бизнеса
Это не CRM. Не ERP. Не Trello с кастомными статусами. Это всё сразу, но на языке, который точно соответствует тому, чем компания занимается.
Разница тонкая, но решающая. Если софт называет заказ «deal», «opportunity» или «task», команда никогда не будет пользоваться им стабильно. Если он называет его «ЗН» и имеет статусы, которыми команда и так мыслит — замер, макет, согласование, печать, резка, слесарка, производство, монтаж, отгрузка, счёт, — внедрение происходит само.
Это и есть главный аргумент за заказной софт в сервисном бизнесе: дело не в фичах. Дело в языке.
Технические решения, которые влияют на бизнес
Каждый технический выбор здесь сделан исходя из операционного эффекта, а не из того, что интересно разработчику.
База — реляционная MariaDB, а не модный NoSQL. Потому что у заказа жёсткие связи с клиентом, позициями, историей и счетами, а когда бухгалтеру понадобится годовой отчёт, SQL — язык, который умеет читать много людей.
Аутентификация использует bcrypt для новых пользователей, но сохраняет совместимость с устаревшим MD5. Не элегантно. Прагматично: существующим пользователям не нужно восстанавливать пароль в день миграции, а это разница между «пользуется вся команда» и «половина сдалась».
Фронтенд — быстрая SPA под Nginx, за ней Fastify на Node.js. Можно было бы сделать классическое Rails-приложение с рендером на сервере. SPA выбрана по конкретной причине: монтажники на объекте обновляют статусы с телефона, часто при слабом сигнале. SPA с локальным состоянием и асинхронной синхронизацией работает в таких условиях лучше, чем система, требующая полного round-trip на каждый клик.
Это единственная причина, по которой выбор оправдан. Если бы все сидели в офисе на оптоволокне, традиционное приложение обошлось бы дешевле и в разработке, и в поддержке.
Моделирование реального процесса: проблема статусов
Самая частая ошибка при оцифровке такого бизнеса — свести реальный процесс к трём-четырём статусам: ожидает, в работе, завершено. На диаграмме чисто, в поле бесполезно.
Domínio Visual работает с десятью отдельными статусами. Каждый соответствует физической фазе работы и конкретной команде или ответственному:
- Закрыт (0) — финальный статус после выставления счёта
- Замер (1) — менеджер выезжает замерить
- Макет (2) — дизайнер делает визуальное предложение
- Печать (3) — винил или печатный материал
- Резка (4) — буквы или жёсткий материал
- Слесарка (5) — металлокаркас, если нужен
- Производство (6) — сборка в цеху
- Монтаж (7) — установка у клиента
- Отгрузка (8) — логистика доставки
- Счёт (9) — выставление счёта
- Согласование макета (10) — клиент утверждает перед печатью
Такая гранулярность — не инженерный перебор. За каждым статусом стоит конкретный человек, которому нужно знать «что сейчас у меня». Склеивание двух статусов в один означает, что этот человек начнёт видеть чужие заказы. Внедрение разваливается мгновенно.
История: невидимая фича, которая решает больше, чем любая другая
У каждого заказа есть связанная таблица истории. Каждая смена статуса, каждая заметка, каждое вложение фиксируются с таймстемпом и автором изменения.
На этапе сбора требований эту фичу никто не просит, а через полгода она становится самой востребованной. Потому что решает три операционные боли, которые не выглядели техническими задачами:
Когда клиент звонит с претензией, любой сотрудник может восстановить точную хронологию работы, не полагаясь на чью-то память.
Когда внутри идёт спор «кто кому что сказал», есть нейтральная запись, которая закрывает его за секунды.
Когда в команду приходит новый человек, он разбирается в контексте старых заказов, не допрашивая пятерых коллег.
Правило простое: если какая-то вещь способна породить вопрос «а когда именно…» или «а кто это сделал…» через три месяца — она обязана быть в истории. Всегда.
Что почти всегда идёт не так с первой попытки
Стоит быть конкретным насчёт ошибок, которые встречаются почти в каждом таком проекте, чтобы те, кто сейчас решает запускать, знали, чего избегать.
Ошибка первая: начинать с модуля счетов. Интуитивно — именно там заходят деньги, значит, это приоритет. Это неверно. Если остальная система не используется, счета продолжают выставляться вне системы, как раньше. Начинай с операционного статуса заказов; счета подтянутся сами.
Ошибка вторая: спрашивать мнение всей команды до начала разработки. Каждый оптимизирует софт под свой кусок процесса, и получается Франкенштейн из противоречивых фич. Выбери одного-двух опытных людей, которые видят бизнес от начала до конца, и игнорируй остальных до появления рабочей версии, на которую можно реагировать.
Ошибка третья: не мигрировать историю. Новая система без последних двух лет работы — пустая система. Команда продолжает лазить в старую за прошлым. Миграция данных занудна, технична и не блистает, но без неё внедрение всегда будет половинчатым.
Ошибка четвёртая: дашборды до процесса. Графики руководство смотрит раз в неделю. Процесс каждый день использует вся команда. Платформа без дашбордов, но с рабочим процессом полезна с первого дня. Обратное — нет.
Хорошие практики, работающие в любом сервисном бизнесе
Domínio Visual — вывески, но шаблон применим к любой компании, которая продаёт проекты: креативные агентства, стройка, архитектура, автосервисы, типографии, AV-интеграторы, event-агентства.
- Моделируй статусы, которыми команда уже мыслит, а не те, что красиво смотрятся на диаграмме
- История каждого заказа — обязательна, не опциональна
- Гибридная аутентификация во время миграции — не заставляй всех восстанавливать пароль в первый день
- Реляционная база для операционных данных; если потом понадобится сложная аналитика — экспортируй
- Интерфейс рассчитан на телефон со слабым сигналом, а не на офисный монитор
- Счета — после того как операционный процесс устоялся, никогда до
- Один внутренний ответственный с правом решать, а не комитет
Готовый софт против заказного
Правильный вопрос — не «а разве заказной не дороже?». Дороже. Вопрос в другом: сколько стоит то, что команда действительно будет пользоваться системой каждый день и не бросит её через три месяца?
Готовый софт — Monday, Asana, HubSpot с кастомными полями — дешевле на входе. И стабильно дороже в эксплуатации, потому что команде приходится мысленно переводить язык софта на язык бизнеса. Этот перевод рушится ровно тогда, когда система нужнее всего: под давлением, с раздражённым клиентом, у горящего дедлайна.
Заказной софт с собственным языком этот перевод убирает. Стартовый ценник выше. Совокупная стоимость владения за пять лет почти всегда ниже. А ценность структурированных операционных данных в твоей собственной схеме — которую можно запрашивать, экспортировать, анализировать без оглядки на лимиты сторонних экспортов — трудно переоценить.
Это не универсальное правило. Маленькая команда на старте пусть сидит на Notion или в таблице, пока это не станет невыносимым. Как только стало невыносимо — пора строить.
Безопасность и непрерывность
Платформа, которая ведёт заказы, клиентские данные и историю счетов, быстро становится критичной для бизнеса. Это требует трёх дисциплин, которые сервисные компании традиционно недооценивают.
Бэкапы. Не еженедельные. Минимум ежедневные, в идеале почасовые инкрементальные. Протестированные. Непроверенный бэкап — это надежда, а не гарантия. Делай полное восстановление в отдельной среде хотя бы дважды в год.
HTTPS обязателен, сертификаты автоматически обновляются через Let's Encrypt. Это норма с 2016 года, но до сих пор встречаются компании со сломанным замком в браузере. В 2026 году нет технического оправдания отдавать бизнес-приложение по HTTP.
Разграничение доступа по ролям. Не всем нужно видеть всё. Если менеджеру не нужны маржа — он её не видит. Если монтажнику нужен только адрес и время — он видит только это. Принцип наименьших привилегий, который OWASP описывает десятилетиями, — это не паранойя, это базовая гигиена.
GDPR: что меняется, когда софт свой
Сервисные компании в Португалии работают с персональными данными клиентов: имена, адреса, контакты, часто налоговый номер. Статья 6 GDPR требует чёткого правового основания для обработки, статья 32 — соответствующих технических мер.
Собственный софт даёт здесь конкретные преимущества: ты реализуешь нужную политику хранения, псевдонимизацию там, где это уместно, право на удаление без тикетов во внешнюю поддержку и журналы «кто что сделал». Готовый SaaS даёт всё это в теории; на практике каждая из этих возможностей зависит от тарифа и скорости ответа саппорта.
Реальная стоимость: о чём молчат предложения
В таком проекте, если делать его хорошо, четыре компоненты стоимости, которые большинство коммерческих предложений недооценивает.
Разработка — видимая часть: сборка приложения, дизайн, тесты, выкатка в прод. Обычно 40–60% стоимости первого года.
Миграция данных всегда недооценивается. Вытащить данные из таблиц, отсканированных бумажек, старых систем и привести их к пригодному для импорта виду занимает больше времени, чем предполагает любая разумная оценка. Закладывай не меньше 15% бюджета.
Обучение и сопровождение в первые недели. Первые две недели после запуска решают, приживётся ли система. Наличие человека, готового отвечать на вопросы, быстро чинить мелкие баги и дорабатывать UX-детали, — это и есть разница между «команда внедрила» и «команда вернулась в WhatsApp».
Текущая поддержка. Сервер, бэкапы, обновления безопасности, небольшие ежемесячные доработки. Предсказуемая месячная сумма, которую многие компании предпочитают делать вид, что её нет, пока система не ляжет.
Признаки того, что пора
Несколько конкретных сигналов, от мягких к серьёзным, что сервисный бизнес упирается в потолок ручного управления:
- Клиенты звонят спросить про заказы, а тебе нужно обойти трёх человек, прежде чем ответить
- Главный держатель центральной таблицы ушёл в отпуск — и бизнес замедлился
- Выясняется, что заказы, завершённые недели назад, так и не выставлены к оплате
- Внутренние споры заканчиваются фразой «я думал, этим занимаешься ты»
- Новым сотрудникам нужны недели, чтобы понять, где что лежит
- При росте на 20% координация ухудшается экспоненциально вместо линейной нагрузки
Если узнаёшь два-три пункта — скорее всего, пора. Если четыре и больше — пора было ещё два года назад.
Главные выводы
Сервисному бизнесу не нужна эффектная технология. Нужна система, которая говорит на правильном языке, фиксирует реальный статус работы, ведёт проверяемую историю и работает на телефоне у того, кто сейчас в поле.
Выбор между готовым и заказным — это решение о совокупной стоимости владения и реальной вероятности того, что команда внедрит инструмент. Готовое дешевле запустить; заказное дешевле поддерживать и использовать. Для критичных операций заказное почти всегда выигрывает за три–пять лет.
Миграция — это вопрос управления изменениями больше, чем инженерии. Готовый софт — необходимое, но недостаточное условие. Без внутреннего ответственного с полномочиями и без серьёзной миграции исторических данных даже лучшая система останется наполовину внедрённой.
Следующий материал — о противоположном: когда разумно оставить всё в таблицах и не поддаваться соблазну цифровизировать слишком рано. Не каждая компания готова, и иногда постройка системы — способ отложить операционные решения, которые должны быть приняты раньше.