AI Assist
Питання «взяти готове чи замовити розробку» звучить як питання про бюджет. Насправді це питання про те, наскільки ваш бізнес схожий на середній. Коробкові рішення роблять для середнього випадку — і коли ви в нього потрапляєте, це найрозумніша покупка на ринку. Проблема починається, коли ви в нього не потрапляєте, а розумієте це вже після оплати річної підписки.
Розберемося чесно: де межа, скільки насправді коштує кожен варіант за два роки, які витрати обидва табори замовчують і чому найчастіша правильна відповідь — не «або-або», а третій варіант.
Що таке «готове рішення» насправді
Під готовим рішенням на ринку розуміють щонайменше три різні речі, і плутанина тут коштує дорого.
Конструктор сценаріїв. Ви самі збираєте дерево гілок мишкою: кнопки, повідомлення, умови. Дешево, швидко, повний контроль над логікою — але логіку доводиться будувати вам, і жодного розуміння мови там немає. Класика для FAQ і меню.
SaaS-платформа підтримки. Готовий продукт із власним інтерфейсом оператора, чергами звернень, шаблонами й уже вбудованим ШІ-модулем. Ви підключаєте канали, завантажуєте базу знань і працюєте. Це найбільш «коробковий» варіант: багато функцій із першого дня, але ви живете за правилами платформи.
Галузеве рішення. Бот, зроблений під конкретну нішу — салони, стоматологія, доставка. Всередині вже є розуміння предметної області: поняття «майстер», «слот», «послуга». Якщо ваша ніша збігається — це найшвидший старт із можливих.
Спільна риса всіх трьох: ви купуєте чужу модель вашого бізнесу. Якщо вона збігається з реальністю — ви економите купу грошей. Якщо ні — ви платите за те, щоб підганяти свій бізнес під чужу модель.
Що входить у кастомну розробку
Кастом — це не «те саме, але дорожче». Це інший склад робіт, і більша частина бюджету йде не туди, куди очікують.
Типовий розподіл на реальному проєкті виглядає так: приблизно чверть часу — збір і структурування бази знань, ще чверть — інтеграції з вашими системами, приблизно стільки ж — проєктування сценаріїв і меж повноважень, і лише решта — власне код бота й інтерфейси. Тобто ви платите переважно за те, щоб система знала ваш бізнес і вміла працювати з вашими даними.
Що ви отримуєте натомість:
- логіку, яка повторює ваші процеси, а не навпаки;
- інтеграції з тими системами, які у вас реально стоять, включно з саморобними;
- дані у себе: історія діалогів, база знань і аналітика лишаються вашими;
- відсутність стелі за обсягом — вартість не стрибає, коли звернень стає вдвічі більше;
- можливість змінювати поведінку системи, не чекаючи на роадмап вендора.
Головний недолік теж очевидний: більший вхідний бюджет і довший старт. Плюс залежність від підрядника, про що чесно поговоримо нижче.
Де готове рішення впирається у стелю
За нашою практикою бізнес приходить із коробки до кастому за п’ятьма типовими сценаріями. Якщо впізнали свій — ви вже на межі.
1. Інтеграція, якої немає. Найчастіша причина. Платформа підтримує двадцять популярних CRM, а у вас саморобна база, галузева система обліку або 1С. Вендор чесно каже «через API можна» — і виявляється, що API або немає, або він односторонній, або доопрацювання коштує як половина розробки.
2. Дані потрібні в реальному часі. Коробка вміє відповідати з завантаженого тексту. Але клієнт питає не «які у вас ціни взагалі», а «чи є ця модель у наявності зараз». Якщо система не бачить залишків у момент розмови, вона або мовчить, або бреше — і другий варіант гірший.
3. Процес складніший за діалог. Запис до майстра — це діалог. А от прийом заявки на ремонт, де треба перевірити гарантію, підібрати сервісний центр, зарезервувати деталь і сформувати документ — це процес. Коробкові рішення не проєктувалися під процеси, лише під переписку.
4. Обсяг зробив підписку дорожчою за розробку. Тарифи за діалог виглядають нешкідливо на тисячі звернень і починають боляче кусатися на десяти тисячах. Це чиста арифметика, і її легко перевірити — калькулятор нижче.
5. Бот став частиною продукту. Якщо ви продаєте послугу, всередині якої працює бот, віддавати його чужій платформі означає віддавати контроль над якістю власного продукту й даними клієнтів.
Пройдіть дерево рішень — воно веде саме цими розвилками й показує не лише вердикт, а й шлях, яким ви до нього дійшли.
Скільки це коштує за два роки
Найпоширеніша помилка при виборі — порівнювати разову вартість розробки з місячною вартістю підписки. Це порівняння ні про що: у першому випадку сума кінцева, у другому — щомісячна й зростає разом із вами.
Коректний спосіб — сумарні витрати за фіксований горизонт. Два роки — розумний строк: за менший період кастом майже завжди програє, за більший майже завжди виграє, а двадцять чотири місяці показують реальну картину для більшості бізнесів.
Порухайте повзунки під свої цифри. Модель побудована на середніх ринкових тарифах SaaS-платформ і наших реальних кошторисах.
Зверніть увагу на поведінку графіка: точка окупності зсувається вліво передусім через кількість діалогів і кількість менеджерів у системі. Саме за них платформи беруть найбільше. Якщо у вас невеликий потік і один-два оператори, коробка виграє впевнено — і це нормальний результат.
Приховані витрати готового рішення
Цінник на сайті вендора — не вся сума. Ось що зазвичай виринає після старту.
Оплата за місця. Більшість платформ рахує не тільки діалоги, а й операторів. Виріс відділ — виріс рахунок, навіть якщо навантаження на бота не змінилося.
Функції за межами тарифу. Аналітика, кілька мов, розширені інтеграції, вивантаження даних, зняття брендингу вендора — усе це регулярно живе в старшому тарифі, який виявляється вдвічі дорожчим за той, на який ви орієнтувалися.
Робота з обмеженнями. Витрата, яку ніхто не планує: години вашої команди, витрачені на обхідні шляхи. Вивантажити звіт руками, бо потрібного немає. Дублювати запис у CRM, бо інтеграція одностороння. Пояснювати клієнтам, чому бот не бачить їхнє замовлення. За рік це складається в помітні гроші, просто вони не мають рядка в бюджеті.
Прив’язка до вендора. Історія діалогів, налаштування й база знань живуть у платформі. Переїзд означає почати частину роботи заново, і чим довше ви на платформі, тим дорожчий вихід.
Приховані ризики кастому
Було б нечесно перелічити мінуси лише одного варіанта. У розробки свої слабкі місця, і про них треба знати до підписання.
Залежність від підрядника. Головний ризик. Якщо код і документація погані, а команда зникла, ви лишаєтеся з системою, яку ніхто не може супроводжувати. Це вирішується на етапі договору: код і доступи належать вам, документація здається разом із проєктом, стек — поширений, а не екзотичний.
Довший шлях до першого результату. Коробка працює завтра, кастом — через місяць. Якщо гроші горять зараз, розумно запустити щось просте паралельно з розробкою, а не чекати.
Ризик переускладнити. Класична пастка: замовник хоче автоматизувати все й одразу, бюджет роздувається втричі, а половина сценаріїв потім не використовується. Ліки прості — запускати вузько, на найчастіших зверненнях, і розширювати за даними.
Підтримка — це теж стаття витрат. Кастом не «зробили й забули»: змінюються API месенджерів, оновлюються моделі, з’являються нові сценарії. Закладайте супровід у бюджет одразу, інакше система тихо застаріє за рік.
Чотири міфи про кастомну розробку
Міф перший: це дорого. Дорого — поняття відносне до альтернативи. Розробка агента з двома інтеграціями коштує приблизно як два-три місяці роботи одного менеджера підтримки. Питання не в тому, чи це велика сума, а в тому, за скільки місяців вона повертається на вашому обсязі. Для бізнесу з тисячею звернень на місяць це зазвичай півроку-рік, для десяти тисяч — кілька місяців.
Міф другий: це довго. Довго — коли намагаються запустити все одразу. Перша працююча версія на найчастіших сценаріях виходить за два-три тижні, і вже вона знімає більшу частину навантаження. Решта добудовується за даними, паралельно з роботою. Проєкти, що тягнуться пів року, майже завжди страждають не від складності, а від відсутності пріоритетів.
Міф третій: підтримувати зможе тільки автор. Це правда лише для поганого коду. Нормальний проєкт віддається із документацією, зрозумілою структурою й поширеним стеком — і будь-який компетентний розробник входить у нього за кілька днів. Закріпіть це в договорі, і міф перестане бути ризиком.
Міф четвертий: потрібна власна команда розробників. Не потрібна. Потрібна одна людина з вашого боку, яка знає ваші процеси й може відповідати на питання про них. Це найчастіше керівник відділу, а не технічний спеціаліст: більшість питань у таких проєктах не про технології, а про те, як у вас насправді влаштована робота.
З чого складається кошторис
Прозорість тут корисна обом сторонам, тому покажемо структуру витрат на типовому проєкті.
Аналіз і база знань. Розбір ваших процесів, збір документів, приведення прайсу й умов до несуперечливого вигляду, підготовка матеріалів для навчання. Часто найважча частина, бо вимагає вашого часу — але саме вона визначає, чи буде система відповідати правильно.
Інтеграції. Найбільш передбачувано оцінювана частина: вартість прямо залежить від кількості систем і від того, наскільки вони готові до підключення. Популярна хмарна CRM з документованим API — це кілька днів. Саморобна база без документації — це тижні, і чесний підрядник скаже про це одразу.
Сценарії й межі повноважень. Проєктування того, як агент поводиться в різних ситуаціях, включно з поганими: клієнт незадоволений, дані суперечать одні одним, потрібної інформації немає. Ця частина рідко видна в комерційній пропозиції, але саме вона відрізняє систему, яка витримує реальність.
Тестування на реальних діалогах. Прогін системи на вашій справжній переписці за минулі місяці. Дешевий і найкорисніший етап: він показує помилки до того, як їх побачать клієнти.
Супровід. Щомісячна стаття: моніторинг якості відповідей, оновлення бази знань, адаптація до змін в API месенджерів. Закладайте її одразу — система без супроводу помітно деградує за рік.
Гібрид: третій варіант, про який рідко говорять
На практиці найчастіша правильна відповідь — не «або-або». Готова платформа й власна розробка чудово поєднуються, якщо розділити ролі.
Схема перша: коробка як канал, кастом як мозок. Платформа лишається інтерфейсом оператора й точкою підключення месенджерів — це та частина, яку немає сенсу писати самим. А логіка відповідей, робота з базою знань і дії у ваших системах виносяться у власний сервіс, який спілкується з платформою через API.
Схема друга: коробка на простому, кастом на складному. Типові звернення закриває готове рішення, а сценарії, що вимагають ваших даних і дій, маршрутизуються у власного агента. Клієнт різниці не помічає.
Схема третя: кастом як прошарок інтеграцій. Ви лишаєте платформу цілком, але дописуєте інтеграційний шар, який стикує її з вашими системами так, як штатні конектори не вміють.
Гібрид виграє тим, що ви платите за розробку лише тієї частини, де коробка справді не дотягує, а не переписуєте з нуля те, що вже працює.
Як стеля виглядає на практиці
Опишемо збірний, але типовий сюжет — ми бачимо його з невеликими варіаціями кілька разів на рік.
Інтернет-магазин підключає коробкову платформу. Перші місяці все добре: бот відповідає на питання про доставку й оплату, знімає з менеджерів десятки однакових повідомлень, підписка коштує менше за каву для офісу. Усі задоволені.
Далі накопичуються дрібниці. Клієнти дедалі частіше питають не «як у вас із доставкою», а «де моє замовлення» — і бот цього не бачить, бо не має доступу до системи. Менеджери починають дублювати відповіді руками. З’являється сезон, потік зростає втричі, і рахунок за діалоги зростає разом із ним. Маркетинг просить звіт за джерелами звернень, а в платформі такого зрізу немає — доводиться вивантажувати й зводити в таблиці.
Через рік картина така: підписка коштує вже помітних грошей, троє людей витрачають години на обхідні шляхи, а бот закриває дедалі меншу частку звернень, бо найцінніші питання вимагають даних, до яких він не має доступу. Формально система працює. Фактично вона перестала розв’язувати задачу.
Помітити цей момент вчасно допомагає одна проста метрика: частка звернень, які система закрила повністю, без участі людини. Якщо вона місяць за місяцем падає, а рахунок росте — ви вже під стелею, навіть якщо все начебто працює.
Як перейти з готового на власне без втрат
Якщо ви вже рік на платформі й розумієте, що впираєтесь у стелю, міграція не мусить бути болючою. Порядок дій такий.
Спершу заберіть дані. Вивантажте історію діалогів і базу знань, поки маєте доступ. Це найцінніше, що у вас є: реальні питання клієнтів своїми словами — найкращий матеріал для навчання нової системи, і купити його ніде.
Визначте, що працює. З аналітики видно, які сценарії реально використовуються. Переносити треба їх, а не весь функціонал платформи — зазвичай виявляється, що з тридцяти можливостей у справі десь п’ять.
Запускайте паралельно. Новий агент бере на себе один канал або один тип звернень, стара система продовжує працювати. Порівнюєте якість на реальному трафіку, а не на демо.
Перемикайте поступово. Канал за каналом, сценарій за сценарієм. Підписку скасовуєте останньою — економія в тисячу доларів не варта ризику лишитися без підтримки клієнтів на тиждень.
Чек-лист перед рішенням
Сім питань, які варто закрити до того, як щось підписувати.
- Чи є в готовому рішенні інтеграція саме з вашою системою — і двостороння вона чи тільки на читання?
- Скільки коштуватиме підписка при подвоєнні потоку звернень і зростанні команди?
- Чи можете ви вивантажити свої дані з платформи в нормальному форматі й чи це не коштує окремо?
- Які саме функції входять у ваш тариф, а які тільки у старший?
- Якщо кастом — кому належать код, доступи й документація після завершення проєкту?
- Хто супроводжує систему через рік і скільки це коштує?
- Що станеться зі зверненнями, які система не зможе обробити — куди вони підуть?
Останнє питання найважливіше й найчастіше пропущене. Будь-яка автоматизація має чіткий план для випадків, коли вона не спрацювала.
Що обрати: коротка відповідь
Готове рішення чи кастомна розробка — це вибір не за бюджетом, а за тим, наскільки ваші процеси схожі на середні. Коробкове рішення виграє, коли задача типова: відповіді на питання, збір контактів, невеликий потік і популярна хмарна CRM — тут підписка обійдеться дешевше за будь-яку розробку, а запуск займе дні. Кастомна розробка чат-бота стає обґрунтованою, коли ви впираєтеся в одну з п’яти стель: немає інтеграції з вашою системою, потрібні дані в реальному часі, автоматизувати треба процес, а не переписку, обсяг зробив підписку дорожчою за розробку або бот став частиною вашого продукту. Порівнювати варіанти треба сумарними витратами за два роки, а не разовою сумою проти місячної, і враховувати приховані статті: оплату за місця, старші тарифи, години команди на обхідні шляхи й вартість виходу з платформи. І пам’ятайте про третій варіант: гібрид, де готова платформа лишається каналом, а власна розробка бере на себе логіку та інтеграції, часто дає найкраще співвідношення ціни й контролю — ви платите за розробку лише тієї частини, де коробка справді не дотягує.
Не впевнені, у який бік хилитися? Ми безкоштовно подивимося на ваші процеси й скажемо чесно — навіть якщо чесна відповідь буде «беріть коробку». Напишіть нам або подивіться, як ми робимо ШІ-агента з продажів.
