Розробка порталу весільної агенції: де ламається облік заявок
Весілна агенція рідко страждає від браку звернень — страждає вона від того, як вони обліковуються. Заявки надходять у Telegram, на робочий телефон і у форму на сайті, осідають у листуванні менеджера, частина дописується в загальну таблицю. Каталог локацій і підрядників живе окремим файлом, який оновлюють вручну з пам'яті.
Поки звернень небагато, розбіжність непомітна.
У сезон, коли за день надходить десяток пар, таблиця і листування розходяться: одна дата опиняється у двох списках, підряднику підтверджують вікно, яке вже зайняте, а заявка з месенджера чекає відповіді, поки менеджер закриває попередній запит.
Ціна такого обліку — не «незручність», а пари, що пішли, і зірвані бронювання.
Дата йде до конкурента, поки узгоджують склад і кошторис, підрядник відмовляється працювати після накладки, а особистий кабінет пари, де видно статус, договір і оплату, підміняється десятком дзвінків і уточнювальних повідомлень.
Розробка порталу для весільної агенції починається з єдиного контуру: одне сховище замість таблиць, автоматичний збір звернень з месенджерів, пов'язаний каталог локацій і підрядників, особистий кабінет пари з прозорими статусами.
Розбираємо, як це закривається і що саме ламається, якщо залишити облік заявок весільної агенції на ручному введенні.
Що змінюється після запуску: швидкість обробки і клас відмов
Портал змінює не лише вітрину, а й такт роботи агенції: заявка з будь-якої сторінки потрапляє в одну чергу, а не розходиться поштою, месенджерами і блокнотом адміністратора. Нижче — що перевіряємо на прийманні через місяць після запуску і які показники вважаємо нормою.
Строк обробки заявки
Маршрутизація заявки йде за типом події, датою і поточним завантаженням менеджера, а не за принципом «хто перший побачив». Перша відповідь скорочується з годин до хвилин, і час до розрахунку кошторису перестає залежати від того, хто сьогодні на зміні.
Завантаження менеджерів і ручні операції
Дані з форми лягають у картку одразу: пара, дата, локація, орієнтир за бюджетом. Перенесення вручну і повторного уточнення тих самих деталей більше немає — менеджери звільняють помітну частку часу на дзвінки, підбір локацій і зустрічі замість введення.
Прострочені задачі й повторні звернення
У кожного етапу є строк: не відповіли протягом доби — задача спливає у керівника. Прозорість воронки і звітність за заявками збираються автоматично, тому «загублені» пари й повторні звернення видно у звіті того ж дня, а не в розборі сезону.
| Процес | Зараз | Після запуску |
|---|---|---|
| Перша відповідь на заявку | від кількох годин, вручну | хвилини, за чергою менеджерів |
| Передача заявки | листування, усні домовленості | призначення в картці, з історією |
| Контроль строків | з пам'яті керівника | автоматичні нагадування й ескалація |
| Звіт за заявками | зводиться вручну до кінця місяця | збирається за кожним етапом онлайн |
Варіанти збірки: готове ядро, конструктор, окрема реалізація
Варіант збірки визначає не зовнішній вигляд порталу, а те, скільки унікальної логіки доведеться в нього закласти.
У весільної агенції така логіка зазвичай одна: календар зайнятості локацій і підрядників, прив'язка заявки до вільної дати, розподіл звернень між менеджерами і різний доступ для пари, агенції та підрядника. Саме вона найчастіше конфліктує з типовими сценаріями готових рішень.
| Варіант | Коли підходить | Строки запуску | Обмеження рішення |
|---|---|---|---|
| Готове ядро з профільними модулями | Каталог локацій, блог, заявки, базовий особистий кабінет пари | Перші тижні | Логіка бронювання й ціноутворення живе всередині модулів, нестандартні сценарії вирішуються обхідними домовленостями |
| Конструктор сайтів | Односторінковий сайт із формою заявки, мінімум інтеграцій, короткий сезон | Дні | Є стеля за навантаженням у високий сезон, обмежений доступ до даних, немає гнучких вивантажень, переїзд означає перезбирання |
| Власна реалізація | Свій календар зайнятості, ролі підрядників, автоматичний розподіл заявок | Кілька місяців до першого релізу, далі ітерації | Потрібні свої регламенти оновлень, резервне копіювання, моніторинг і супровід |
| Ядро плюс власні модулі | Типовий контент і каталог займають більшу частину, унікальна лише логіка бронювання | Запуск у перші тижні, модулі — слідом | Потребує дисципліни: ядро не можна нескінченно тягнути в бік доопрацювань, інакше втрачається сенс рішення |
Різниця між варіантами проявляється на другий рік роботи, коли змінюються ціни, з'являються нові локації й агенції-партнери.
Перехід з конструктора — це фактично нова збірка з перенесенням даних вручну, а перехід з ядра на власну логіку робиться покроково, модуль за модулем, без зупинки порталу.
Як іде робота: від інтерв'ю до передачі управління
Робота йде ітераціями: кожен наступний етап спирається на результат попереднього, тому рішення ухвалюються на даних агенції, а не на припущеннях. Замовник бачить результат до того, як логіка піде в розробку, і може скоригувати пріоритети.
- Розбір процесів. Інтерв'ю з менеджерами, адміністраторами і підрядниками: як заявка проходить шлях від звернення до підписаного договору, де губиться, що співробітники правлять вручну.
- Схема даних. Фіксуємо сутності — пара, локація, підрядник, кошторис, зайнята дата в календарі, документ — їхні зв'язки і права доступу за ролями.
- Прототип. Клікабельний макет ключових сценаріїв: прийняти заявку, зібрати кошторис, узгодити дату, випустити документи.
- Налаштування інтеграцій. Календарі, пошта, месенджери, бухгалтерія; повторні спроби при збої, щоб заявка не губилася за недоступності зовнішнього сервісу.
- Перевірка на реальних даних. Проганяємо сценарії на минулих заявках агенції: перенесення дат, відмови, знижки, нестандартні комплектації.
- Перенесення даних. Міграція клієнтів, договорів та історії, звірка контрольних сум, паралельний період роботи старої і нової системи.
- Навчання і регламент підтримки. Інструкції за ролями, розбір спірних випадків, вікно реакції на звернення і порядок випуску змін.
До передачі в команди агенції залишається робоча система і зрозумілий порядок її розвитку.
Що передаємо: конфігурації, права доступу, регламенти і схеми
Проєкт не закінчується запуском: ми передаємо комплект артефактів, за якими ваша команда і новий підрядник працюють без нас. Усе лежить у закритому розділі з доступом власника агенції, а не в листуванні.
- Матриця ролей і прав доступу: адміністратор, менеджер, редактор, підрядник-фотограф — свій набір розділів у кожного, адмінські права не роздаються «про всяк випадок».
- Облікові записи зовнішніх сервісів оформлені на агенцію, а не на виконавця: домен, пошта, хостинг, аналітика переходять до вас.
- Налаштовані інтеграції з месенджерами: заявки з сайту і з чатів потрапляють в один канал, шаблони автовідповідей і правила маршрутизації додані.
- Календар зайнятості: зйомки, виїзди і зустрічі менеджерів видно в загальному розкладі, перетин дат блокує сам портал.
- Схема розділів і даних: карта сторінок і зв'язки «пара — локація — підрядник — дата», щоб правки не ламали розрахунок.
- Регламенти експлуатації: резервне копіювання, порядок оновлень, вікна робіт, реакція на збої і відкат до попередньої версії.
- Інструкції для менеджерів: приймання заявки, ведення угоди, публікація кейсу в портфоліо — з розбором типових помилок.
- Пам'ятка підрядникам: як підняти локальну копію, де дивитися журнали і як повідомляти про інцидент.
Передачу закриваємо звіркою: проходимо кожен пункт на живому сценарії — нова заявка, перенесення дати, публікація кейсу.
Кейс: сезонний пік заявок і облік у таблицях до і після
Як було
Весілна агенція Levanda приймала заявки в чотирьох таблицях і трьох месенджерах: звернення з сайту, лист, повідомлення в месенджері і дзвінок жили кожне на своєму місці.
У сезонний пік з травня по вересень надходило до 20 звернень на день, і частину з них ніхто не бачив до вечора. Пари писали повторно або йшли до тих, хто відповідав першим.
За сезон набралося близько 600 звернень, і 18–22% з них не отримали відповіді взагалі. Середній час відповіді клієнту — від 4 до 18 годин, а заявки вихідних чекали до понеділка. Менеджери тримали статуси в голові, дублювали записи і не бачили, хто з колег уже перевантажений.
Що змінили і що стало
Ми зібрали єдиний реєстр пар: заявки з форм, пошти і месенджерів потрапляють до нього автоматично, дублі склеюються за телефоном і адресою пошти. Розподіл іде за поточним завантаженням менеджера, на кожне звернення ставиться строк реакції, а нагадування надходить до його спливу. Дата весілля, локація та історія листування залишаються в картці пари.
Відповідь у робочий час скоротився до 15 хвилин, частка загублених заявок — нижче 2%. Завантаження менеджерів вирівнялося: розрив між найзайнятішим і найвільнішим скоротився з чотириразового до півтораразового. Звіт за джерелами і часткою переходів у договір збирається автоматично, без ручної звірки таблиць.
Чим каталог підрядників відрізняється від особистого кабінету пари
Каталог підрядників — публічна частина системи. Він працює без авторизації, тримає фільтри за типом послуги, містом і вільними датами, віддає картки з портфоліо та відгуками і має витримувати трафік від пошукових роботів і рекламних кампаній. Збій тут коштує дорого: каталог, що впав, втрачає заявки, які ще не дійшли до агенції.
Особистий кабінет пари вирішує зворотну задачу — він закритий і персональний. Тут видно статуси бронювання за кожним підрядником, листування, документи (договір, рахунок, програма дня) і список задач зі строками: підтвердити меню, вибрати декор, внести правки. Дані не повинні відкриватися за прямим посиланням.
Саме тому ролі користувачів і розмежування доступу проєктуються окремо від каталогу. Пара бачить лише своє весілля, підрядник — лише свої підтверджені заявки, менеджер агенції — свій напрямок, адміністратор — усе.
Права перевіряються на рівні конкретного запису, а не сторінки: інакше підрядник за чужим ідентифікатором в адресі витягне дані іншої пари.
Друга причина тримати частини окремо — різний життєвий цикл даних. Каталог змінюється рідко і віддається з підготовлених сторінок, а статуси бронювання змінюються щодня і тягнуть за собою повідомлення, історію і відкати: скасування броні, перенесення дати, повторна заявка. Якщо змішати це в одному інтерфейсі, кожна зміна статусу зачіпає публічні сторінки.
На практиці це спільний шар даних і два незалежні інтерфейси з єдиним входом у систему. Розробка порталу для весільної агенції будується так, щоб правки в каталозі не ламали кабінет, а зростання кількості пар не прискорювало деградацію публічної частини.
Сумніви щодо техніки: інтеграції, навантаження, міграція
Технічні заперечення щодо порталу зазвичай одні й ті самі: що робити з накопиченими таблицями, чи витримає система сезон, хто отримує доступ до адмінки і що буде після здачі. Відповідаємо коротко на кожне.
У нас усе в таблицях — переносити вручну?
Ні. Вивантажуємо таблиці, чистимо дублі й приводимо поля до єдиної схеми, заливаємо в базу порталу і звіряємо кількість записів за кожним розділом. Заявки, анкети пар та історія листування переносяться один раз — далі вони живуть у картках, а не у файлах.
Портал витримає сезон?
Пік припадає на кілька місяців, коли заявок у рази більше, ніж у міжсезоння. Заздалегідь перевіряємо систему під навантаження вище реального, виносимо важкі вибірки, кешуємо каталоги і фотографії, вмикаємо автозбільшення ресурсів. У разі зростання трафіку портал масштабується, а не переписується.
Які доступи потрібні вашим інженерам?
Окремі облікові записи з правами лише на потрібний контур: сервер, репозиторій, панель управління. Особисті паролі не запитуємо, ключі видаємо на час робіт і відкликаємо після здачі. Ви будь-якої миті бачите в журналі, хто і що змінював.
Що з резервними копіями і підтримкою після запуску?
Копія бази знімається за розкладом в окреме сховище, раз на місяць перевіряємо її відновленням. Реліз, що ламає бронювання, відкочуємо на попередню версію за хвилини.
Передаємо документацію і навчаємо адміністратора, далі — підтримка за регламентом: інциденти, оновлення безпеки, доопрацювання в міру зростання агенції.
Обговоримо задачу: розберемо процес і повернемося з оцінкою
Розбір задачі починається з процесів, а не зі списку сторінок. Спочатку ми описуємо, як в агенції проходить шлях пари: первинна заявка, підбір локації, узгодження бюджету, робота з підрядниками, фінальний кошторис.
З цієї схеми виростає і структура порталу, і порядок етапів — тому оцінка з'являється лише після того, як процеси зафіксовані й не розходяться з реальністю.
- Розбір процесів — інтерв'ю з менеджерами і координаторами: які заявки надходять, на якому кроці губляться, які узгодження йдуть у листуванні.
- Схема системи — карта розділів, сутностей (пара, локація, підрядник, заявка, кошторис) і зв'язків між ними, включно із зовнішніми сервісами: календар, оплата, розсилки.
- Прототип і ролі — доступи для пари, координатора і підрядника: хто що бачить, змінює і підтверджує.
- План робіт — порядок етапів, склад першої ітерації і те, що свідомо переносимо, із залежностями між блоками.
- Реалізація ітераціями — приймання на кожному етапі, зміни не накопичуються до фіналу.
- Підтримка — регламент оновлень, резервні копії, строки реакції на збої, порядок доопрацювань.
Щоб розбір ішов предметно, надішліть опис поточного процесу, приклади заявок і кошторисів, список сервісів для інтеграції, ролі користувачів і посилання на портали, які подобаються.
Опишіть задачу — повернемося з оцінкою, схемою системи і планом робіт, обговоримо порядок етапів і обсяг підтримки.
