Зараз у мене є клієнт (я про це вже згадував), який хоче вивести в Україну нову бонусну систему. Потихеньку вона переростає в платіжну. Плани надмірно амбітні, а робиться все на коліні. Гроші у клієнта великі, але людина старого гарту і звикла все робити на льоту. Особливо це стосується IT.
Як наслідок, при тестуванні процесу активізації картки потенційним власником виникла купа проблем. Коротко - 3 кроки з поверненням на один крок, 2 кроки для подальшого входу в систему, незручне введення незручного пароля. У підсумку прогнозована ефективність - максимум 10%. Це все наслідок відсутності проектування відвідувальної поведінки.
Мене підрядили описати «логіку того, як працює віконце введення номера картки і зарахування бонусів з відвідувачем». Те, як в даний момент працює вся структура (системою боюся назвати).
Я ж охрестив це «проектуванням відвідувальної поведінки», розбив на три частини: відвідувач без картки + оформлення оператором картки, відвідувач зараховує бонуси на картку, відвідувач розплачується карткою.
По ідеї, все це повинно було бути в одному документі, оскільки все це опис процесу одного скрипту. Але об'єднання логік стало б дуже громіздким і незручним для вивчення, особливо - далеким від IT людям.
На початку роботи, «головний» всього цього підприємства після моїх пояснень і ціни видав: «Та я це за півгодини на коліні з якимось власником магазину за пиво намалюю». Образило, чесно. У підсумку процес, який займає у відвідувача не більше однієї хвилини, був описаний за 4 дні повністю відведених під цю роботу.
Кінцевий варіант і мої рекомендації показали не тільки вузькі місця, а факт, що скриптик, який працює на боці магазину, треба переробляти повністю, і в тому вигляді, в якому він зараз працює, є всі передумови для махінацій, а так само помилок при зарахуванні бонусів на рахунок.
Для себе я поставив завдання зробити процес роботи з карткою в інтерфейсі інтернет-магазину максимально простим, захищеним від помилок і шкідництва, чітко описати поведінку операторів на місцях. І ОБОВ'ЯЗКОВО таким, щоб у разі будь-яких проблем відвідувач міг оперативно, без істерик вирішити їх. Адже проблеми безпосередньо впливають на конверсію в магазині, якщо процес взаємодії з вікном для введення карти буде скрутний - це негайно позначиться на конверсії. І клубна система, взагалі, буде втрачати учасників.
Вийшло, що в спроектованій поведінці (далі коротко називатиму «логікою»), є 3 групи, так званих, зацікавлених осіб. Тобто суб'єкти, які беруть участь у процесі. Оператор, відвідувач і скриптик. Останній теж проводить у логіці важливі дії, тому я і його зарахував до груп зацікавлених осіб.
Описувати весь процес не має сенсу. Схему, за якою складав логіку, ви можете подивитися за цим посиланням, тут тільки найпростіший з трьох сценаріїв поведінки, але структурно зрозуміло, як робилося інше.
Я опишу ключові моменти, які були розкриті завдяки проектуванню процесу.
Зміна вигляду інтерфейсу
У процесі проектування стало ясно, що крім самого поля для введення номера картки, в робочий процес необхідно внести ряд елементів:
- Посилання типу «» Немає картки? Ви її отримаєте безкоштовно! «»;
- Короткий описовий текст;
- Телефон служби підтримки;
- Нове поле введення для валідації власника картки (про це нижче);
- Текст, що видається після валідації власника картки.
У зв'язку з цим я запропонував ввести нескладний pop-up, який би не блокувався браузерами і спец. програмками, із затемненням основного вікна. Жодних спливаючих нових вікон, нових вкладок тощо. Не можна забувати про те, що процес оформлення замовлення повинен бути лінійним, тобто відвідувач плавно переходив з одного вікна в інше без будь-яких істотних змін процесу.
Плюс така дрібниця, як встановлені повторювані цифри карти: 9800000000000 (далі йде змінюється тризначне число).
Валідація власника карти
Це питання можна вирішити двома способами. Прив'язка карти до акаунту відвідувача в магазині. Працює тільки, якщо ви роздаєте карти своїм клієнтам. Один раз прив'язали (або оператор, або сам відвідувач) і далі забули про валідацію, що повторюється, що сильно спростить життя клієнтам конкретного магазину. Але, це вже розбірки самого магазину, відповідно його гроші на доопрацювання функціоналу під прив'язку карти, за це система бонусних карток платити не буде.
Другий варіант - повторювана валідація. Щоразу відвідувач виробляє одну і ту ж послідовність, якщо планує використовувати карту.
Перший спосіб не виключає другий, оскільки клубна бонусна програма передбачає, що є й інші власники карток, які не є вашими клієнтами.
Валідація відбуватиметься через смс, відвідувачеві треба буде ввести код зі смски. Здавалося б, що все просто, «сто разів так робили». Насправді існує кілька моментів, які необхідно продумати:
- Смска не прийшла, що відвідувачеві робити? Тут і з'являється потреба в номері служби підтримки.
- Смска прийшла, але іншій людині (помилилися введенням або хтось зловживає), необхідно продумати, що в смську повинно бути, крім номера валідації, щоб люди не хвилювалися за свої гроші.
Коли я здавав роботу представнику замовника, у нас зав'язався спір з приводу необхідності валідації власника картки за умови, що клієнт просто хоче зарахувати гроші на бонусний рахунок. Здавалося б, навіщо тут валідація? Ніхто ж не захоче зараховувати гроші на чужий рахунок.
Я наполягав на валідації, моїми аргументами були:
- Необхідно попереджати програмно відвідувачів від їх помилок з неправильним введенням карти, я не бачив іншого способу крім валідації; (читаючи Алана Купера, знайшов підтвердження своїх думок на самому початку книги);
- Скрипт не знає, яку операцію хоче зробити відвідувач, тому необхідний введення додаткових кроків, типу checkbox «я хочу витратити бонуси»;
- Дуже багато відвідувачів захочуть витратити бонуси. Тому запитів на checkbox буде переважна більшість. При цьому така ж більшість абсолютно не в курсі, скільки бонусів на рахунку;
- З попереднього пункту виникає проблема перевірки бонусів на рахунку, що передбачає обов'язкову валідацію;
- Клієнт парирував тим, що вони роблять платіжну систему, і, наприклад, більшість користувачів webmoney знають, скільки у них грошей на рахунку. Ось тут, до речі, закралася ключова особливість майбутнього цієї клубної карти. Користувач користується вебманями, щоб оплатити товар, в той час, як купує товар, користуючись карткою, щоб отримати або витратити бонуси. А виходячи з методу і принципів поширення картки, аудиторія буде сприймати її бонусною, як потім клієнт буде працювати зі зміною асоціації мені незрозуміло (вибачте за ліричний відступ);
- Додаткові кроки ускладнюють конверсію. Всім зрозуміло - більше кроків, нижче конверсія;
- Інтернет-магазини класти хотіли на будь-які супер-пупер-гіпер клубні карти, якщо вони зменшують конверсію відвідувачів. Як випливає з попередніх пунктів, ускладнення процесу очевидне, і багато магазинів будуть проти таких складнощів.
Ускладнення процесу очевидне, причому з'являється купа умов, які природно будуть лягати в скрипт і в проектування відвідувальної поведінки.
Мені знадобився цілу годину, щоб переконати представника клієнта в моїй правоті.
Підтвердження суми бонусів на рахунку
Система влаштована так, що після валідації власника карти, скрипт отримує залишок бонусів за картковим рахунком та інші дані. Відповідно в пам'ять скрипту на боці магазину заноситься інформація про доступну суму бонусів.
Зловмисник може навмисно спробувати обдурити магазин в цей момент, наприклад витративши частину бонусів на поповнення мобільного телефону, тому я передбачив повторний запит по балансу, після натискання кнопки «оплатити».
Функція резервування бонусних засобів
Нинішня реальність інтернет-магазинів така, що замовленого відвідувачем товару може не опинитися в наявності. Відповідно подібні випадки необхідно передбачити в логіці програмуліни, яка відправляє дані на сервак системи.
Я рекомендував функцію резервування коштів на рахунку відвідувача, у випадках, якщо він оплачує бонусними коштами замовлення. Гроші повинні йти з рахунку клієнта, і потрапляти в якийсь буфер, чекаючи підтвердження з боку оператора, який виходячи з ситуації, або скасовує проведення операції, або підтверджує.
Природно передбачена повна заміна замовлення, з можливістю оператором у телефонному режимі (з клієнтів на дроті) вилучити бонусні кошти з рахунку клієнта.
Порятунок менеджерів
Ця функція прийшла в останній момент. Справа в тому, що помиляються не тільки відвідувачі, а й оператори. Ні для кого не секрет, що в запарі помилитися або ввести щось неправильно простіше простого. Я рекомендував у функціоналі скриптика додати для адміністрування замовлення такий checkbox: «я підтверджую, що повторив (а) відвідувачеві дані картки». Кумедний той факт, що в цьому випадку юзабіліті checkbox повинен бути жахливий - тільки при кліці на сам квадратик. Тільки поставивши галочку, оператор зможе провести подальші зміни замовлення.
Ця функція маленька дрібниця, але врятує багато нервів операторам і власникам магазинів через розгляди і повернення коштів.
Підсумок
Деякі з перерахованих вище функцій можуть комусь здатися банальними або пустяковими. Хочу зауважити лише одне, саме такі пустякові банальності і випускаються з уваги, під час першого запуску нового сервісу або навіть цілого інтернет-магазину. Швидше за все, я не зміг передбачити всіх проблем, які виникнуть в цьому процесі, але, принаймні, скоротив їх кількість.
Я усвідомлюю, що в моїх термінах і підході є частка ламерства, але вважаю, що в цілому це не сильно вплинуло на результат.
Для власників інтернет-магазинів накидав чек-лист деяких моментів, про які забувають при підключенні всякої сторонніх скриптів, або укладаючи договір з якою-небудь клубною системою:
- Перевірте договір, щоб було ясно вказано, хто відповідає за отримані від магазину гроші (гроші клієнтів);
- Уважно прочитайте розділ з розірванням договору. Хто кому і що буде винен;
- Гарненько задумайтеся, що станеться, якщо магазин вийде з системи? У випадку з моїм клієнтом, у магазину є можливість просто платити за використання системи, як якийсь сервіс. Припинення програми буде болючим процесом для ваших клієнтів;
- Вивчіть процес повернення грошей системою вам. Терміни, комісії і тд.
- Уважно вивчіть юзабіліті та інтерфейс пропонованого скрипту. Від нього може дуже сильно залежати майбутня конверсія.
