За 9 років роботи я нарешті заробив 20 баксів для Wix

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Майже 9 років (гей, скоро там пенсія вже?) працюю у Wix і досі не можу сформулювати, яка у мене насправді посада. Напевно краще за все сказати, що я роблю те, що потрібно і намагаюсь не робити те, що не потрібно.

TLDR;
Буду відвертим: мені запропонували написати цей текст, бо ми наразі робимо доволі цікавий продукт і будуємо локальну команду. І за звичайних обставин я б відмовив (бо не потрібно), але в цей раз у мене є меркантильна причина: розповісти про корисну бібліотеку, яку ми зробили як сайд-ефект роботи над цим проєктом. Тому я згадав підліткову ідею стати журналістом, зробив клікбейт-заголовок і написав цю статтю про проєкт, про бібліотеку, про команду, але почав...

... Трохи більше, ніж 4 роки тому в подкасті Юри Федоренко та ДОУ я розмірковував, чим мені далі займатись, бо як інжиніринг-менеджер доволі великої команди я зробив все, щоб вона працювала автономно, майже без втручань, і мені, якщо чесно, стало доволі нудно.

Потім почалась повномасштабна і я займався, окрім менеджменту, багатьма дуже неспецифічними для себе речами: спочатку керування евакуацією, згодом організація закупівель всього, що потрібно: від броників до корчів для колег, що пішли боронити державу (досі займаюсь). Я також грав роль менеджера продукту для інструменту перевірки «чи всі ок», який ми запускаємо після кожного обстрілу (досі граю). Про виклики, які постали в перші місяці, я згадував у своєму блозі.

Коли ж все стало повертатись до більш-менш звичного ритму, і я нарешті був удома в Києві, питання, чим займатись далі, знов стало актуальним. Згодом я доєднався до CTO Office команди в компанії. CTOO це така (доволі велика) команда старпьорів (якщо казати літературно: досвідчених спеціалістів), яка займається експериментальними проєктами або приходить на допомогу туди, де зараз є фокус компанії.

І саме тоді почався AI-бум. Я часто жартую: сьогодні можна вказати пальцем на випадкову людину в офісі і, скоріш за все, вона робить щось пов’язане з AI. Я — не вийняток. Наша частина команди почала експериментувати з AI, з фокусом на відвідувачах сайтів наших користувачів, або як ми кажемо Users of Users.

Уявимо, що у вас є бізнес: ви щось продаєте або надаєте послуги та побудували сайт на нашій платформі.

У вас з’являються клієнти — відвідувачі вашого сайту. Вони шукають інформацію про ваші сервіси та продукти, часто пишуть вам в чат, надсилають листи або дзвонять із запитаннями (іноді ігноруючи наявну інформацію, іноді справді не знаходячи): «Чи є у вас така сукня зеленого кольору?», «Скажіть, чи вільний слот на консультацію в четвер о 17.00?» і так далі.

Щоб не втрачати клієнтів, потрібно відповідати на такі запитання 24/7. Ми вирішили побудувати агента, який знає все про ваш сайт і бізнес, про ваші продукти та послуги, про ваш розклад, faq і так далі — усю публічну інформацію — і відповідає за вас, як цілодобовий менеджер вашого онлайн-бізнесу.

Десь рік тому ми побудували «нульову версію», запросили перших користувачів, зібрали аналітику і відгуки, щоб зрозуміти, що потрібно зробити в першу чергу для публічного релізу.

Я дозволю собі трошки похизуватись різними фічами та тим, як зростала команда відтоді.

scrollTo(🤔)

По-перше, було важливо зробити новий чат-віджет, який повинен гнучко налаштовуватись в плані дизайну: наші користувачі мають шалені, напевно найкращі інструменти кастомізації будь-якого компонента, який є у них на сторінці, і ми не виключення. Але це не дуже складна та доволі зрозуміла задача для інженерів у Wix.

А от будь-хто з фронтенд-інженерів, які зараз читають цю статтю, стикались з тим, як важко робити зручні чати. Перш за все, тому що потрібно одночасно контролювати положення скролу і за потреби змінювати його в правильну позицію. Прийшло нове повідомлення — куди скролити треба? Донизу чи в початок нового повідомлення? Разом з цим потрібна віртуалізація списку, інакше скрол буде пригальмовувати. Потрібно довантажувати історію повідомлень і робити її prepend, зберігаючи при цьому позицію скролу, щоб UI не здригався. Одночасно нові повідомлення приходять в кінець списку (append), і чи потрібно взагалі туди зміщати скрол, якщо ти в цей час читаєш історію?

Якщо коротко, контролювати стан скролу в динамічному вікні — одна з найскладніших задач у фронтенд-розробці. Я почав шукати й не знайшов жодної бібліотеки, яка б значною мірою розв’язувала всі проблеми, що постають в розробці фронтенду чатів. Тому ми зробили таку. Мій колега Denys Dovhan працював над цією задачею, тому, якщо вам потрібно зробити чат, що наразі дуже актуальна задача для багатьох, рекомендую придивитись до цієї бібліотеки.

Backoffice і Playground

По-друге, потрібно було зробити бек-офіс для налаштувань. Це не просто boolean-галочки, це великий інтерфейс керування агентом. Там у нас є ще один чат-інтерфейс (як добре, що у нас вже є бібліотека для цього)! Це — Playground, де власник або менеджер сайту може перевірити, як агент буде відповідати на питання. Якщо відповідь здається хибною, завжди можна її скоригувати та таким чином зробити RAG-документ. Для цих документів є окремий інтерфейс, де можна додавати знання, що з якихось причин відсутні на сайті. Або навіть обмежувати агента у випадках, коли відвідувач торкається теми, яку ви бажаєте ігнорувати.

Наприклад: ви не хочете публікувати номер телефону на сайті, але додаєте такий RAG: «якщо відвідувач питає номер телефону, відповідай „+380...“». Або навпаки: «Якщо відвідувач питає про річний прибуток цього інтернет-магазину, відповідай, що „ця інформація недоступна“».

Також є купа додаткових налаштувань, як-то стиль мови агента, довжина відповіді, розклад, коли він працює (наприклад в «тільки вихідні» та «не в бізнес-години», а в робочі години це просто чат з менеджером), і так далі.

Монетизація. Нарешті

Безплатно ми надаємо доволі велику кількість розмов та можливість додавати багато RAG-документів. Сайти з великим трафіком потребують більше можливостей, для цього ми зробили інтеграцію з кастомними Wix Pricing Plans пакетами.

Так вийшло, що весь свій час роботи в компанії, нагадаю, майже 9 років, я завжди приносив користь «не напряму». Мої проєкти або були безплатні, або були частиною стандартних Wix Premium пакетів і доволі важко було відчути мій вплив. Як я люблю жартувати: я краще вмію витрачати гроші компанії, ніж заробляти.

Однак вже за декілька годин після публічного релізу в слак-каналі написали: «у нас є перша підписка!» Доволі скоро була друга і третя, і так далі. По-перше, ми підтвердили, що наш продукт потрібен, по-друге, у мене з’явилась нова тема для жарту: за 9 років роботи я нарешті заробив 20 баксів для компанії.

Команда

Я обіцяв також розказати про побудову команди. Коли я доєднався, я був єдиною людиною в команді в Україні. Але ми почали доволі швидко зростати: хтось, як і я, перейшов з інших команд, когось з інженерів ми наймали.

Сьогодні нас вже семеро, і, я сподіваюсь, поки ви читаєте цю статтю, до нас в Києві доєднається також новий менеджер продукту.

Це дуже важливо і я завжди наголошую: якщо є значна кількість інженерів в однієї локації, там також повинен бути й менеджер продукту. Також вважаю це важливим показником продуктової компанії, бо є багато в Україні «продуктових» компаній, де працюють в основному талановиті інженери, а всі рішення стосовно продукту приймаються в «головному» офісі десь в іншій країні. Такий собі «не аутсорс» на мій погляд.

Окремий виклик — це швидка комунікація та швидке прийняття рішень, що доволі важко зробити, коли питання виникають в однієї локації, а відповідь знаходиться в іншій. Тому ми зростаємо і кількістю, і якістю.

Про фідбек

Перш ніж перейти до продукту, розкажу трохи про фідбек. Він важливий, хоча іноді корисно вміти його ігнорувати.

Як тільки у будь-якого продукту з’являються користувачі, важливо дивитись перш за все на показники, а не на фідбек. Банальні: кількість інсталяцій vs кількість видалень, кількість активних користувачів в день і так далі. Та складніші (на прикладі нашого застосунку): скільки робочого часу ми звільняємо нашим користувачам або скільки товарів та послуг було продано завдяки розмові з нашим агентом.

На жаль, ми, люди, звертаємось до фідбек-форми тільки у випадку, коли щось нам не підходить, тому так — дивитись на скарги важливо. Виправляти помилки, додавати функціональність чи покращувати дизайн також важливо. Але ще важливіше це не змінювати фокус через те, що хтось залишив не добрий відгук, і лагодити щось невеличкому відсотку людей, шкодячи чомусь насправді важливому.

Наведу приклад. Уявимо, що хтось не може розібратись, як налаштувати агента так, щоб він відповідав таким чином, як бажає менеджер сайту ресторану. Причина — меню ресторану на сайті це просто pdf, і він не індексується системою. В роадмапі ми можемо підвищити пріоритет задачі про індексацію контенту з pdf, doc тощо, або додати підтримку нового Wix MCP сервера, який додасть можливість робити дії на сайті (замовляти сервіси або додавати продукти в кошик), що можна робити через інтерфейс агента.

Емоційно дуже хочеться розв’язати проблему реального користувача, який витратив час і залишив відгук. Але чи насправді це важливіше за інші речі? Пропоную в коментарях написати вашу думку.

Також важливо іноді збирати та ділитись з командою гарними відгуками, які трапляються не так рідко, як іноді здається. Нещодавно ми читали такий (мій переклад з англійської):

Я не можу бути більш вдячним Wix за такий якісний безплатний сервіс! Я протестував його на реальних питаннях, які задають мої клієнти, відповіді дуже схожі на те, як я відповів би самостійно, цей продукт економить мені багато часу!

Погодьтесь, читати та ділитись такими відгуками доволі приємно.

Буду радий, якщо ви протестуєте застосунок на своєму Wix-сайті та залишите відгук: https://www.wix.com/app-market/web-solution/wix-ai-assistant-client

А перед нами ще багато викликів: інтеграція з новими Wix MCP серверами, краща підтримка різних мов, нові можливості відображення контенту. Можливо, навіть генерація UI-агентом та керування голосом.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.