УРОК 05 / 14 · БЕЗКОШТОВНИЙ КУРС ДЛЯ БІЗНЕСУ
Плани перетворюють вашу послугу на пропозицію, яку клієнти можуть зрозуміти. Корисний план описує роботу, яку він підтримує, що до нього входить і коли клієнтові потрібно більше. Він також встановлює межі, які дають вам змогу стабільно виконувати обіцянку.
Наприкінці: створіть коротку матрицю планів, поясніть логічний шлях переходу на вищий план і перевірте важливі обмеження. Ціни в цьому уроці є ілюстративними; ціноутворення та витрати ви розглянете в уроці 9.
Почніть із різних ситуацій клієнтів
Оригінальний приклад FitSite розділяє індивідуальних тренерів, усталені спортзали та бізнеси з кількома локаціями. Це корисні гіпотези, оскільки робота може відрізнятися: тренеру потрібна чітка професійна присутність, завантаженому спортзалу може знадобитися розширений розклад і процес бронювання, а мережі може бути потрібна інформація для кожної локації.
Не припускайте, що кількість працівників визначає правильний продукт. Індивідуальний тренер може значною мірою покладатися на онлайн-бронювання, тоді як більший спортзал уже може мати систему, яку хоче зберегти. Використовуйте інтерв’ю, щоб виявити суттєві відмінності в робочому процесі, складності, підтримці та масштабі. Плани мають відображати ці відмінності, а не стереотипи.
Для іншого SaaS-бізнесу межею може бути один проєкт проти командного робочого процесу, епізодичне використання проти частого, або одна локація проти кількох. Оберіть невелику кількість зрозумілих ситуацій. У прикладах часто трапляються три рівні, але для початку може бути достатньо однієї доброї пропозиції або двох чітких варіантів.
Сформулюйте обіцянку до списку функцій
Для кожного плану напишіть речення, що пояснює корисний результат для клієнта. Потім перелічіть функції та сервісну роботу, потрібні для його досягнення. Якщо ви не можете пояснити роль функції в цьому результаті, перегляньте, чи належить вона до початкової пропозиції.
Базовий план усе одно має виконувати обіцяну роботу. Видалення важливої функції лише для того, щоб змусити перейти на вищий план, може зробити стартовий план невдалим. Якщо клієнт не може використовувати ваш «сайт для бронювання», щоб приймати бронювання або спрямовувати до них, або змініть обіцянку, або додайте працездатний спосіб бронювання.
Додайте операційні деталі, потрібні клієнтам для ухвалення рішення: кількість сайтів або робочих просторів, відповідні ліміти використання, доступність власного домену, підтримувані інтеграції, обсяг підтримки та будь-які послуги налаштування. Пояснюйте обмеження просто. Технічні квоти важливі, коли вони впливають на надання послуги, навіть якщо вони не мають домінувати в заголовку.
Використовуйте матрицю FitSite як робочий приклад
- Starter — ілюстративно $49/місяць: один сайт студії з шаблоном Studio Essential, основною інформацією про бізнес і способом зв’язку. Чітко вкажіть, чи входять посилання на бронювання та власні домени.
- Growth — ілюстративно $99/місяць: один сайт із додатковими варіантами шаблонів і перевіреним процесом бронювання або роботи з контентом, що відповідає потребам покупця. Вкажіть межі підтримки та інтеграцій.
- Pro — ілюстративно $199/місяць: підтримка погодженої конфігурації для кількох локацій, наприклад до п’яти сайтів, із відповідними шаблонами та обсягом обслуговування.
Ці цифри зберігають оригінальний навчальний приклад; вони не є ані ринковими орієнтирами, ані рекомендацією щодо ціноутворення. Ви повинні перевірити свої витрати та реакцію покупців. Не обіцяйте «усі преміумплагіни», якщо ліцензування, підтримка та сумісність не дають змоги це виконати. Довший список функцій може збільшити витрати без покращення результату для клієнта.
Будьте точними щодо лімітів. Якщо Pro включає п’ять сайтів, зазначте, чи квота сховища застосовується до кожного сайту окремо або до всієї підписки відповідно до фактичної конфігурації. Сторінка з кількома локаціями на одному сайті — не те саме, що п’ять незалежних сайтів. Не допускайте, щоб таблиця цін і наданий продукт описували різні речі.
Перетворіть матрицю на налаштування продукту
У додатковому напрямі WordPress Ultimate Multisite підтримує плани, шаблони та ліміти. Створіть продукт для кожного запланованого плану та налаштуйте доступні варіанти шаблонів, підтримувані плагіни й теми, дозволену кількість сайтів та інші відповідні квоти. Зверніться до актуальної документації щодо елементів керування, доступних у вашій версії.
Продумано використовуйте стандартні налаштування плагінів. Контактна форма може бути частиною кожного сайту, тоді як спеціалізована інтеграція потрібна лише там, де вона необхідна. Плагіни, активовані для мережі, завантажуються по всій мережі; не припускайте, що налаштування плану може запобігти такій поведінці. Перевіряйте реальний досвід клієнта для кожного рівня та не стверджуйте, що функція обмежена планом, якщо вона залишається доступною.
Розглядайте дозволи окремо від маркетингу. Надавайте клієнтам доступ, потрібний для підтримки їхнього контенту, а адміністрування платформи залишайте під своїм контролем. Тестуйте новий обліковий запис клієнта на кожному плані, а не перевіряйте лише з погляду адміністратора мережі.
Тримайте публічну таблицю порівняння та внутрішній контрольний список надання послуги разом. Коли функція змінюється, оновіть обидва перед тим, як пропонувати переглянутий план. Це допоможе уникнути продажу старої обіцянки під час надання нової конфігурації.
Спроєктуйте підвищення та зниження планів до початку продажів
Клієнт має розуміти, що змінюється під час переходу між планами. В Ultimate Multisite перегляньте налаштування груп планів і переходів на вищий/нижчий план для встановленої версії, а потім протестуйте дозволені переходи. Візуальний порядок, як-от Starter, Growth, Pro, корисний лише тоді, коли відповідна поведінка переходів йому відповідає.
Зниження плану заслуговує на особливу увагу. Що відбувається, якщо клієнт має більше сайтів, сховища або користувачів, ніж дозволяє нижчий план? Що відбувається з власним доменом чи інтеграцією? Визначте процес, який зберігає дані клієнта та повідомляє про необхідні зміни. Не обіцяйте автоматичне видалення, миттєвий перерахунок чи негайне повернення коштів без підтвердження запланованої поведінки білінгу.
Тестуйте зміни планів у контрольованому тестовому платіжному середовищі, де це підтримується. Перевіряйте дати поновлення, відображувані ціни, права доступу та електронні листи клієнтам. Зафіксуйте все, що потребує ручної підтримки, щоб чесно визначати ціну та пояснювати це.
Помірно додавайте необов’язкові доповнення
Джерело пропонує додаткове сховище, пріоритетну підтримку та додаткові сайти. Це можуть бути корисні доповнення, якщо клієнти їх розуміють і ви можете надійно їх надавати. Починайте з реального регулярного запиту, а не додавайте варіанти оформлення замовлення лише тому, що програмне забезпечення їх підтримує.
Для кожного доповнення визначте одиницю, ціну, період оплати, умови скасування та відповідальність за надання. «Пріоритетна підтримка» потребує конкретного обсягу та очікуваного часу відповіді; вона не має означати гарантоване вирішення. Додаткове сховище потребує вимірюваного ліміту та чіткого визначення, чи воно є спільним.
Зробіть доповнення явно необов’язковими та уникайте попередньо вибраних платежів. Урок 6 охоплює представлення пропозиції під час оформлення замовлення. Просте рішення про купівлю легше тестувати й підтримувати, ніж велику колекцію пакетів із правами, що перетинаються.
Ваша вправа: застосуйте урок на практиці
Створіть односторінкову матрицю планів і контрольний список тестування:
- Назвіть свої перші сегменти клієнтів і результат, який обіцяє кожен план.
- Перелічіть потрібні функції, обмеження, обсяг підтримки та винятки простою мовою.
- Додайте попередні ціни з позначкою «ілюстративно — потребує перевірки», а також орієнтовні витрати на надання послуги.
- Опишіть один сценарій підвищення та один сценарій зниження плану, зокрема що відбувається після перевищення ліміту нижчого плану.
- Якщо ви використовуєте WordPress, налаштуйте по одному тестовому обліковому запису для кожного плану та порівняйте наданий досвід із матрицею.
Ваш результат: пропозиція, яку ви можете пояснити в короткій розмові, з чіткими межами та переліком налаштувань або поведінки білінгу, які ще потребують перевірки.
Перш ніж рухатися далі
- Плани мають відповідати корисним ситуаціям клієнтів і залишатися життєздатними для надання.
- Прикладові ціни є припущеннями, доки їх не підтвердять витрати та дані про клієнтів.
- Тестуйте ліміти, доступність плагінів, підвищення та зниження планів, а не покладайтеся на таблицю цін.
Джерела та додаткове читання
Адаптовано з оригінального уроку про веббізнес. Ultimate Multisite: плани, ліміти та керування плагінами