Які сервіси ми маємо на увазі
Онлайн-сервіс відрізняється від звичайного сайту тим, що в ньому є результат для користувача. Ось кілька типових прикладів:
- онлайн-запис і бронювання: лікарі, тренування, номери, столики, оренда обладнання;
- калькулятори й конфігуратори, які видають розрахунок, комерційну пропозицію чи документ;
- сервіси за підпискою: доступ до тренувань, курсів, даних, інструментів для роботи;
- сервіси для замовлення технічних ресурсів, наприклад серверів чи ліцензій, з автоматичною видачею доступу;
- внутрішні інструменти компанії, які автоматизують окремий процес і доступні клієнтам онлайн.
Якщо ж у системі багато груп користувачів із різними кабінетами і великий обсяг матеріалів, задача ближча до веб-порталу.
Новий продукт чи сервіс для наявного бізнесу
Новий продукт насамперед має довести, що він комусь потрібен. Тут важлива швидкість першого запуску й гнучкість: після розмов з користувачами функції часто змінюються. Технічні рішення ухвалюємо так, щоб їх можна було переглянути без переписування всього коду.
Сервіс для діючої компанії вже має клієнтів і процеси. Головне тут — не зламати те, що працює: сервіс має обмінюватися даними з CRM, обліковою системою, телефонією. Ризик, що сервіс не знайде попиту, нижчий, зате більше вимог до стабільності й інтеграцій.
Перша версія чи одразу повний продукт
Мінімальна перша версія містить лише ключову дію і найнеобхідніше навколо неї. Плюси — менший початковий бюджет, швидша зустріч з реальними користувачами, менше грошей на функції, які нікому не знадобляться. Мінуси — продукт виглядає скромно, а частину процесів на старті доведеться робити вручну.
Повний продукт виправданий, коли ринок і користувачі вже відомі, наприклад ви переносите в онлайн сервіс, який давно працює офлайн. Плюс — клієнти одразу отримують усе. Мінус — більший ризик витратитися на зайве, якщо припущення не підтвердяться.
Ми чесно скажемо, який варіант бачимо розумнішим для вашої ситуації, і поясним чому.
Оплати, підписки й гроші користувачів
Платіжна частина — найчутливіше місце сервісу. Помилка в ній означає або втрачені гроші, або розлючених клієнтів. Тому окремо продумуємо:
- що відбувається, якщо оплата не пройшла або платіжний сервіс тимчасово недоступний;
- як працюють пробний період, перехід між тарифами і скасування підписки;
- які листи й повідомлення отримує людина на кожному кроці;
- як ваша команда бачить оплати і може вручну виправити спірну ситуацію.
Для українського ринку зазвичай використовуємо LiqPay, WayForPay або Monobank, для міжнародного — Stripe чи PayPal. Вибір залежить від країн клієнтів і моделі оплати.
Окремо налаштовуємо фіскальні чеки та рахунки для юридичних осіб, якщо ваші клієнти — компанії. Це часто забувають на старті, а потім доводиться терміново доробляти, коли перші бізнес-клієнти просять акти й рахунки для бухгалтерії.
Інтеграції та робота з телефона
Сервіс майже завжди спирається на зовнішні системи: календарі, CRM, сервіси розсилок, карти, бази даних партнерів. Що більше таких зв’язків, то важливіше передбачити, що станеться при збої кожного з них. Детальніше про це — на сторінці інтеграцій та автоматизації.
Багато сервісів відкривають переважно з телефона. Тому сценарії проєктуємо спершу для маленького екрана. Якщо користувачі повертаються щодня, можна зробити сервіс прогресивним веб-додатком, який встановлюється на телефон без магазину застосунків.
Що підготувати перед стартом
- Опис проблеми, яку вирішує сервіс, і того, як люди вирішують її зараз.
- Портрет перших користувачів і, якщо можливо, кілька людей, готових подивитися прототип.
- Модель заробітку: підписка, разова оплата, комісія чи сервіс безкоштовний для клієнтів вашої компанії.
- Список систем, з якими сервіс має обмінюватися даними.
Типові помилки при запуску сервісу
- Занадто багато функцій у першій версії. Запуск відкладається, а користувачі зрештою користуються третиною можливостей.
- Обов’язкова реєстрація на першому кроці. Якщо людина ще не розуміє, що отримає, вона просто піде. Часто краще показати результат, а реєстрацію попросити пізніше.
- Відсутність аналітики на старті. Без неї неможливо зрозуміти, де користувачі зупиняються, і наступний реліз будується на здогадках.
- Слабка адмін-панель. Команда вручну виправляє записи в базі даних замість того, щоб працювати з клієнтами.
Як зрозуміти, що сервіс працює
Кількість відвідувачів мало що говорить про сервіс. Набагато важливіше, яка частка людей доходить до ключової дії, скільки з них повертаються вдруге і скільки переходять з безкоштовного режиму на платний.
Ці показники ми закладаємо в аналітику ще до запуску. Через деякий час після старту разом розбираємо, на якому кроці втрачаються користувачі, і саме з цього починаємо планувати наступний реліз. Так розвиток продукту спирається на поведінку реальних людей, а не на список побажань, складений до запуску.
Що впливає на вартість онлайн-сервісу
- Складність ключового сценарію: простий запис чи розрахунок з десятками параметрів і правил.
- Платіжна модель: разова оплата, підписки з тарифами, комісії з кількох сторін.
- Кількість ролей: лише клієнт і адміністратор чи ще виконавці, партнери, менеджери.
- Інтеграції: скільки зовнішніх систем і наскільки вони стабільні.
- Очікуване навантаження: сотні користувачів на день чи пікові хвилі одночасних звернень.
Першу оцінку даємо після опису ключового сценарію, точнішу — після прототипу. Окремо показуємо, що входить у першу версію, а що логічно відкласти, щоб ви могли керувати бюджетом за пріоритетами продукту.
Часті запитання
Чи можна запуститися без дизайну, на готовому шаблоні? Можна, для перевірки ідеї це розумний варіант. Але ключовий сценарій все одно варто продумати окремо, бо саме від нього залежить, чи повернуться користувачі.
Чи буде мені належати код? Так, сервіс розробляється для вас, і ви можете розвивати його з нами або з іншою командою.
Що робити, якщо сервіс почне швидко рости? Архітектуру закладаємо так, щоб навантаження можна було розподіляти. Слабкі місця видно з моніторингу, і масштабуємо їх поступово, а не переписуємо все одразу.
Як захищені дані користувачів? Паролі не зберігаються у відкритому вигляді, дані карток обробляє платіжний сервіс, а не ваш сервер. Доступ команди до персональних даних обмежуємо ролями і ведемо журнал дій.
Чи допоможете зі стратегією продукту? Ми допомагаємо сформулювати першу версію і пріоритети релізів, а рішення про ринок і модель заробітку ухвалюєте ви.
Чому Promodex
Promodex створює веб-продукти з 2015 року. Серед онлайн-сервісів у нашому портфоліо — JustVPS, Online GYM, TickOps та Сервіс планування просторового розвитку громад. Продукт від прототипу до розгортання веде наша власна команда з Києва: дизайнери, розробники, маркетологи. А після запуску ми залишаємося поруч, щоб разом випускати наступні версії.
