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 API на 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-інтеграторів, івент-агенцій.
- Моделюй стани, якими команда вже оперує подумки, а не ті, що виглядають чисто на діаграмі
- Історія кожної роботи — обов'язкова, а не опціональна
- Гібридна автентифікація під час міграції — не змушуй усіх відновлювати пароль у перший день
- Реляційна БД для операційних даних; якщо згодом потрібна буде складна аналітика — експортуй
- Інтерфейс для телефона з поганим зв'язком, а не для офісного монітора
- Виставлення рахунків — після того, як операційний потік усталився, ніколи раніше
- Один внутрішній відповідальний із правом рішення по проєкту, а не комітет
Про вибір між універсальним ПЗ і ПЗ на замовлення
Правильне питання — не «чи дорожче зробити на замовлення?». Дорожче. Питання: скільки варте те, що команда користується системою щодня і не покине її через три місяці?
Універсальне ПЗ — Monday, Asana, HubSpot із доналаштованими полями — дешевше купити. Воно ж систематично дорожче в підтримці, бо команда має подумки перекладати словник ПЗ на словник бізнесу. Цей переклад провалюється саме тоді, коли система найпотрібніша: під тиском, із роздратованим клієнтом, при стислому дедлайні.
ПЗ на замовлення з власним словником усуває цей переклад. Початкова вартість вища. Загальна вартість володіння за п'ять років майже завжди нижча. А цінність того, що операційні дані структуровані у твоїй власній схемі — яку можна запитувати, експортувати, аналізувати без залежності від обмежених експортів третіх сторін — важко переоцінити.
Це не універсальне правило. Маленька команда на старті має користуватися Notion чи таблицею, доки не стане боляче. Коли стає боляче — сигнал будувати.
Безпека і неперервність
Платформа, що керує замовленнями, даними клієнтів і історією рахунків, швидко стає критичною для бізнесу. Це вимагає трьох дисциплін, які сервісні компанії традиційно недооцінюють.
Резервні копії. Не щотижневі. Щоденні як мінімум, в ідеалі погодинні інкрементальні. Протестовані. Невипробувана копія — це надія, а не гарантія. Виконуй повне відновлення в окремому середовищі принаймні двічі на рік.
Обов'язковий HTTPS і автоматично поновлювані сертифікати через Let's Encrypt. Це стандарт з 2016 року, і досі трапляються компанії зі зламаним замочком у браузері. У 2026 році немає технічного виправдання віддавати бізнес-застосунок через HTTP.
Контроль доступу за роллю. Не всім потрібно бачити все. Якщо менеджеру не треба бачити маржу — він її не бачить. Якщо монтажнику потрібна лише адреса і час — тільки це і з'являється. Принцип найменших привілеїв, який OWASP описує десятиліттями, — не параноя, а базова гігієна.
GDPR: що змінюється з власним ПЗ
Сервісні компанії в Португалії працюють із персональними даними клієнтів: імена, адреси, контакти, часто ІПН. GDPR у Статті 6 вимагає чіткої правової підстави для обробки цих даних, а Стаття 32 — відповідних технічних заходів.
Власне ПЗ дає тут конкретні переваги: можна реалізувати адекватне збереження даних, псевдонімізацію там, де є сенс, право на видалення без залежності від тікетів до зовнішніх постачальників, і аудитовані логи «хто що зробив». Універсальний SaaS теоретично дає все це; на практиці кожна з цих можливостей залежить від тарифного плану і реакції підтримки.
Реальна вартість: про що мовчать комерційні пропозиції
Такий проєкт, зроблений добре, має чотири складові вартості, які більшість пропозицій недооцінює.
Початкова розробка — видима частина: створення застосунку, дизайн, тести, вихід у продакшн. Зазвичай від 40% до 60% загальної вартості в перший рік.
Міграцію даних завжди недооцінюють. Витягнути дані з Excel'ів, сканованих паперів, старих систем і перетворити їх на щось узгоджене для імпорту займає більше часу, ніж припускає будь-яка розумна оцінка. Закладай щонайменше 15% бюджету.
Навчання і супровід у перші тижні. Перші два тижні після запуску вирішують, чи приживеться впровадження. Наявність людини, доступної для відповіді на питання, швидкого виправлення малих багів і коригування UX, — це те, що відрізняє «команда прийняла» від «команда повернулася до WhatsApp».
Поточна підтримка. Сервер, бекапи, оновлення безпеки, невеликі щомісячні покращення. Передбачувана щомісячна сума, яку багато компаній воліють удавати, що її немає, доки система не зламається.
Ознаки, що настав час це зробити
Кілька конкретних сигналів — від найм'якшого до найсерйознішого — які вказують, що сервісна компанія досягла межі ручного управління:
- Клієнти телефонують із питаннями про роботи, і щоб відповісти, треба перепитати трьох людей
- Людина, яка веде головний Excel, пішла у відпустку — і бізнес сповільнився
- Виявляєш роботи, завершені тижні тому, за які так і не виставили рахунок
- Внутрішні суперечки закінчуються фразою «я думав, цим займаєшся ти»
- Нові співробітники тижнями не можуть зрозуміти, де що знаходиться
- При зростанні на 20% координація погіршується експоненційно замість масштабуватися лінійно
Якщо впізнаєш два-три з цих сигналів — ймовірно, час настав. Якщо впізнаєш чотири чи більше — час настав ще два роки тому.
Ключові висновки
Сервісному бізнесу не потрібна вражаюча технологія. Йому потрібна система, що використовує правильний словник, фіксує реальний стан роботи, зберігає аудитовану історію і працює на телефоні тих, хто на об'єкті.
Рішення між універсальним і замовним — це рішення про загальну вартість володіння і про реальну ймовірність впровадження командою. Універсальне дешевше запустити; замовне дешевше підтримувати й використовувати. Для критичних операцій замовне майже завжди виграє за три-п'ять років.
Міграція — це більше питання управління змінами, ніж інженерії. Готовність ПЗ — необхідна умова, але недостатня. Без внутрішнього відповідального з повноваженнями і без серйозної міграції історичних даних навіть найкраща система залишиться наполовину прийнятою.
Наступний редакційний матеріал дивиться на протилежне: коли має сенс залишити все в таблицях і протистояти спокусі цифровізувати зарано. Не кожна компанія готова, і іноді побудова системи — це спосіб відкласти операційні рішення, які треба ухвалити раніше.