Інтеграція інтернет-магазину INTERTOP з ERP і CRM-системою

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

Саме про такий кейс — створення інтернет-магазину для мережі INTERTOP — ми й хочемо розповісти. У ньому було багато «викликів»: зробити швидко; об'єднати фізичні магазини та онлайн-майданчик у єдиний простір, де клієнтам доступні всі звичні можливості; перенести без втрати якості весь маркетинговий комплекс з офлайну в онлайн. Але головне, що хочеться обговорити, — нюанси, які завжди виникають у подібних глобальних проєктах: як будувати комунікацію із замовником, як розставляти пріоритети в розробці, як уникати створення функціоналу, яким потім ніхто не користується, як шукати баланс між вимогами бізнесу й обмеженнями системи.

Ситуація та завдання

INTERTOP — велика взуттєва мережа, що має понад 200 магазинів в Україні та Казахстані. В офлайні мережа працює давно й успішно, зібравши велику та лояльну аудиторію. В онлайні ж її присутність до 2015 року обмежувалася сайтом-вітриною, який виконував здебільшого інформаційні функції: відгуки покупців, новини, анонси нових акцій.

До сайту додавався інтернет-магазин, але з дуже обмеженим функціоналом: урізаний асортимент, маркетингові акції на онлайн-товари не поширювалися, покупці не мали можливості скористатися знижками чи бонусами. Тобто продажів, порівняно з офлайновими магазинами, сайт практично не генерував.

Розшифруємо це трохи. Щоб онлайн-платформа стала самостійним каналом, її потрібно повністю інтегрувати з ERP-системою компанії. Щоб робити клієнту індивідуальні пропозиції, пропонувати знижки й бонуси, потрібна інтеграція з CRM-системою — щоб уся історія взаємин із клієнтом була доступна онлайн: коли і які покупки він робив, скільки накопичив бонусних балів, якими акціями скористався тощо. Єдиний інформаційний простір означає, що клієнти мережі перестають бачити різницю між каналами спілкування з INTERTOP: наприклад, приміряючи черевики в реальному магазині й тут же з телефона замовляючи доставку їх собі в інше місто.

Пріоритети: що увійшло в перший реліз

Розробка — процес багатозадачний і довгий за строками, тому для ефективної роботи потрібно правильно розставити пріоритети. Правильно — це так, щоб уже в першому релізі були розв'язані принципові бізнес-задачі замовника й він міг випробувати платформу в реальних робочих умовах.

Задача №1. Повна інтеграція ERP і CRM з інтернет-магазином

Синхронізація залишків, замовлень, даних користувачів, нарахованих і витрачених бонусів. Як платформу для інтернет-магазину обрали корпоративну CMS: у неї відкрита архітектура, доволі широкі вбудовані можливості, а певна гнучкість системи дає свободу реалізовувати нестандартний функціонал, потрібний замовникові. Тут пріоритетними стали такі речі:

• повна інтеграція з внутрішньою обліковою системою (в онлайн «підтягнули» весь 20-тисячний асортимент);
• наповнення контентом — тут ми працювали спільно із замовником, адже у фешн-індустрії максимально якісний контент є головним фактором, що впливає на рішення про покупку. Було важливо викласти описи та якісні фотографії для всього асортименту: починали з трьох фотографій на товар, зараз їх може бути до десяти;
• можливість знайти й обрати товар за брендом, кольором, розміром (поки без порівняння з іншими та перевірки наявності);
• налагодження та спрощення процедури замовлення;
• запуск одразу двома мовами: українською та російською;
• можливість в онлайні користуватися звичними бонусними програмами (в онлайн «підтягнули» всі дані користувачів);
• усунення дублів користувацьких даних і прив'язка бонусних карток.

Що важливо на цьому етапі?

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

Простий індикатор того, що функціонал реалізовано добре: уже в перший місяць роботи магазину 25% покупок здійснювалися з використанням бонусної картки INTERTOP PLUS, яку клієнти реєстрували в особистому кабінеті.

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

Доставка та еквайринг: інтеграція з «Новою поштою»

Задача №2

Інтеграція з еквайрингом і службою доставки «Нова пошта»: автоматична прив'язка до адрес поштових відділень і можливість оформити замовлення незалежно від стану серверів служби доставки.

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

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

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

Маркетинг, якого немає в «коробці»

Задача №3. Часткове впровадження маркетингових інструментів, не передбачених платформою

Обрана CMS — чудова система для розв'язання типових задач, її компоненти надійні та протестовані на сотнях проєктів. Але коли в компанії власний величезний маркетинговий досвід і власні напрацювання, типові рішення не рятують — їх треба доопрацьовувати.

Наприклад, візьмемо представлення асортименту. Усі знають, що при викладенні товарів на полиці магазинів діють певні правила мерчандайзингу, але в онлайні вони ще жорсткіші. Порядок показу товарів відвідувачеві сайту залежить від десятка різних факторів: сезонності, поточних акцій, стану складів, наявності артикулів тощо. Для платформи INTERTOP зробили так, що спочатку показуються новинки, потім сезонна колекція, минула колекція, тимчасово відсутні на складі товари й товари, відсутні давно. Зараз менеджер може зайти в адмін-панель і вказати будь-який сезон, який має показуватися зверху. Наприклад, коли активно продається літнє взуття, можна спеціально підняти нагору щось із іншого асортименту, щоб на хвилі попиту продати ще, скажімо, мокасини. Це бізнес-рішення, яке ухвалюється за ситуацією, тому тут передбачено ручне регулювання, а не автоматичне.

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

Знижки та акції

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

У компанії є 4 види знижок:

• бонусні бали;
• подарункові купони;
• знижка 5% за еквайринг;
• індивідуальна знижка на товар.

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

Доопрацювання знадобилося майже для всіх популярних маркетингових акцій — наприклад, для акції «Купи 3 пари зі знижкою 30% — 50% — 70% (третя — найдешевша!)» або акції «Друга ціна», де спочатку дається регулярна ціна на товар, а потім друга ціна — за акцією. Усі акційні ціни калькулюються в ERP-системі компанії й мають коректно відображатися на онлайновій платформі.

А от акція «Купи 2 певні моделі взуття й отримай подарунок із нової колекції за 1 грн» в онлайні не запрацювала. Це хороший приклад того, що не всі інструменти, ефективні в реальних магазинах, можна перенести в онлайн.

Накрутка бонусів

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

Функціонал «Перевірити наявність в офлайнових магазинах»

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

Омніканальність і момент переходу

Омніканальність, мабуть, найгарячіший тренд в e-commerce. Кожен другий інтернет-магазин декларує свій рух у бік омніканальності. Що це таке? Префікс «омні» перекладається як «наявний усюди». На практиці це означає таке:

• магазин або мережа однаково добре представлені як в офлайні, так і в онлайні — однакові ціни, рівень обслуговування, акції та асортимент;
• в онлайні магазин однаково добре представлений на будь-якому пристрої: ноутбук, планшет, смартфон;
• покупець отримує однаковий досвід і під час візиту в онлайн-версію, і під час візиту у фізичний магазин.

По суті, омніканальність — це абсолютна свобода та зручність для користувача: через який канал взаємодіяти з продавцем, де купити й де отримати товар і як скористатися своїми знижками та бонусами. Наприклад, можна з магазину в Одесі оформити доставку обраної пари взуття в Дніпропетровськ, де клієнт забере її в обумовлені строки; можна зарезервувати якусь пару в конкретному магазині й пізніше викупити її. Як показала практика, близько 40% замовлень онлайн — це резерви та пікапи. І для нас, і для замовника це стало несподіванкою — ще один приклад відмінності онлайну від офлайну. Виявилося, людям зручно дорогою кудись захопити з магазину свою покупку.

Важливо спостерігати за користувачами й усе доопрацювання ґрунтувати на їхній поведінці. Люди не розділяють канали! Для них і замовлення на сайті, і візит у реальний магазин — це все INTERTOP. І ми теж маємо прибирати відмінності, робити так, щоб вони функціонували за єдиними правилами.

Наприклад, як реалізовано процес замовлення: користувач обирає на сайті місто, в якому він перебуває. Виходячи з його місцезнаходження, йому показуються товари з актуальними залишками за кожним розміром. Під час покупки він може обрати опцію «Доставка в магазин» і вказати будь-який магазин у будь-якому місті. Взуття доставляється зі складу інтернет-магазину, а якщо потрібна пара вже є в обраному магазині, то резерв оформлюється автоматично. Ця послуга безкоштовна.Олексій Сапунков, керівник проєкту з боку INTERTOP

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

Момент переходу

Для великої мережі перехід в онлайн критичний з погляду збереження рівня сервісу та звичного для клієнта іміджу бренду. Тому й задача тут двокрокова.

1. Не втратити клієнтів. Для цього потрібно, щоб користувачі, авторизувавшись на онлайновій платформі, могли скористатися всіма можливостями, що й у звичному їм реальному магазині.
2. Зробити їм зручно. В онлайні для цього є всі можливості: зручність вибору товару, доставка його звідти, де він є в наявності, туди, куди потрібно клієнту, персоналізований підхід.

Завдяки цим крокам усього за 3 місяці INTERTOP отримав велику лояльну аудиторію в онлайні.

Тонкощі та нюанси активної фази

Розповісти про все, що було зроблено в межах півторарічного проєкту, неможливо. Але ми можемо звернути увагу на важливі речі, щоб ваше спілкування з розробниками було продуктивним.

Спірний функціонал

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

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

Тому нашою першою задачею став пошук консенсусу із замовником щодо двох питань:

• як вибудувати процес, щоб проблеми, з якими зіткнулися співробітники, перетворювалися на задачі на розробку не спонтанно, а з оцінкою їхньої ваги та значущості для бізнесу;
• як знайти баланс між потрібним ступенем автоматизації та ручною роботою в адміністративній панелі.

Завжди є та межа, коли автоматизація несе користь і спрощує процеси в бізнесі. Але за цією межею — невиправдане подорожчання розробки та ускладнення інтеграції між ERP-системою та онлайновою платформою. Цю межу добре ілюструє приклад із присвоєнням ТТН: співробітнику простіше відредагувати введену клієнтом адресу й внести інформацію в потрібні графи (10 секунд), ніж клієнту заповнювати форму з безліччю полів, а розробнику — ускладнювати процес розробки й робити платформу дорогою в підтримці.

Незадіяний функціонал

Ще одна характерна річ — максималізм у вимогах на початкових етапах розробки. Хочеться всього й одразу. Саме так найчастіше з'являється функціонал, який потім не задіюється. З часом він замінюється розумним компромісом між потребами бізнесу й технологічними обмеженнями. Компроміс досягається легше, якщо рішення про впровадження чи переробку функціоналу ухвалюють лише бізнес-підрозділи. Вони щодня відстежують закономірності: чим користувачі активно користуються, де вони «застрягають», звідки йдуть тощо. Якщо доопрацювання пропонується на основі такого аналізу, шанси на те, що воно не буде затребуване в майбутньому, мінімальні.

Пікові навантаження

В e-commerce критично важливою є здатність системи витримувати пікові навантаження, коли в дні акцій і сезонних розпродажів на сайт «прибігає» на 200—500% більше покупців, ніж зазвичай. Архітектуру рішення для такої ситуації важко протестувати за щоденного навантаження.

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

Тестування архітектури проводиться на синтетичних тестах, коли береться історія дій на сайті 50—100 типових відвідувачів, ці сценарії запускаються в кілька тисяч потоків і вимірюється навантаження. Паралельно проводяться органічні тести: статистично аналізується історія дій усіх відвідувачів під час пікових навантажень, що вже були. Так виявляються ділянки системи, які використовуються максимально часто, але відпрацьовують найповільніше. Ще можливі проблемні ділянки — ті, що викликаються не частіше й відпрацьовують не повільніше за всіх, але саме для їхнього функціоналу співвідношення виклики/затримки критичне.

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

Наша помилка

Куди ж без неї. Наприклад, у цьому проєкті ми одразу не подумали, у який спосіб краще реалізувати версію сайту для мобільних пристроїв: робити адаптивну верстку, мобільну версію сайту чи розробляти застосунок. Одразу після запуску мобільний застосунок робити немає сенсу, тому пішли шляхом мобільної версії сайту — показ контенту в окремо розробленому шаблоні. Той функціонал, якого хотів замовник, і ті дизайн-макети, що приходили від дизайнерів, під принцип адаптивності не підходили. Ми пішли на поводу в замовника й дизайнерів, почавши роботу над мобільною версією сайту. Зрозуміло, що всі зміни, які робилися на сайті, доводилося робити двічі — і для мобільної версії теж. Помучившись кілька місяців, ми таки переконали замовника, що дизайн потрібно переробити на адаптивний. Це дорожчий варіант у розробці, але це разове вкладення коштів, на відміну від мобільної версії. Безумовно, ми мали зробити це одразу, наполігши на правильному рішенні.

Комунікації із замовником і документація

Основа та скелет будь-якого проєкту. Якщо ми не хочемо, щоб проєкт зупинився ще на початковому етапі, потрібно вибудовувати й документувати ВСІ процеси, ідеї та обговорення. Від самого початку всі бізнес-процеси з розробки заводяться в систему управління проєктами. Нові релізи плануються завчасно й виходять за чітким графіком. Між релізами допустимі лише критичні зміни (помилки, поломки), які робляться в режимі hot-fix.

У системі управління проєктами є задачі 4 видів:

Цей графік наочно демонструє, як після запуску лавиноподібно зросла кількість запитів на зміни та доопрацювання (червона лінія). Ми не встигали їх виконувати, і зелена лінія показує, яким було відставання за часом реалізації запиту. Проте поступово робота вибудовується, і приблизно через 160 днів ми почали закривати задачі з такою самою швидкістю, з якою вони виникали.

З боку розробників здебільшого висуваються ідеї щодо «пов'язаного покращення»: щоб простіше було реалізувати кілька перспективних доопрацювань, зробімо доробок на майбутнє у вигляді того й того. Наприклад, ми запропонували доопрацювати гео-параметр для фільтра «Наявність товару в торговій мережі», щоб під час перегляду відвідувачем каталогу враховувати його геолокацію й одразу показувати лише доступні йому товари. Як показує Google Analytics, цією функцією активно користуються.

З боку замовника більша частина запитів надходить від бізнес-підрозділів, зокрема маркетингу та продажів. Це природно. Дуже важливо, як поводиться в комунікації IT-відділ замовника, бо саме він має слугувати первинним фільтром для запитів бізнесу.

З IT-відділом INTERTOP ми розмовляли однією мовою. Колеги — професіонали з великим досвідом. Особливо це було помітно на етапі першого релізу, коли панує певний хаос, з боку бізнесу йде багато суперечливих вимог і запитів, і їх треба дуже ретельно фільтрувати, щоб не розпорошуватися й отримати результат в обумовлені строки. Тим більше в нашому проєкті, коли ми за три місяці, включно з першою ознайомчою зустріччю, фактично збудували літак у польоті. Причому намагалися не просто збудувати, а зробити роботу так, щоб потім лише доопрацьовувати й розвивати, а не виправляти.Костянтин Перепечаєнко, керівник проєкту з боку ANIART

Користувацька документація

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

Найкраще з документуванням і описом сценаріїв використання справляються тестувальники — вони багаторазово перевіряють функціонал, знають багато тонкощів і складають найякісніші інструкції. Паралельно ведеться технічна документація для адміністраторів системи з обслуговування, резервування та безпеки. Для них дуже важливим виявився розділ FAQ, де максимально просто були розписані дії як у критичних ситуаціях, так і щоденні обов'язки.

Замовник VS розробник: ступінь залученості

Як і в будь-якій справі: хочете якісного результату — занурюйтеся в роботу разом із підрядником.

1. Участь у розробці з етапу 0. Жодне детальне технічне завдання всіх нюансів у себе не вмістить. Звірятися потрібно на кожному кроці, а для цього представники замовника мають розуміти, на якому етапі розробки ми перебуваємо, куди рухаємося, і вчасно коригувати задачі, якщо цього вимагають змінені бізнес-умови.
2. Перебудова процесів усередині. Краще одразу формулювати KPI — це стимулює менеджерів із самого початку вникати в суть процесів, адже в онлайні по-іншому працює все: маркетинг, логістика, клієнтський сервіс. Наприклад, плануючи розпродаж, треба розуміти, що замовлення може зробити людина з будь-якого куточка країни, тому товари мають бути відповідним чином розподілені по логістичних точках; важливо координувати між собою акції в онлайні та офлайні, щоб не виникало ситуацій із відсутністю товарів на складі.
3. Перебудова процесу спілкування з клієнтами. Онлайн-середовище інше! Не можна перенести процеси з офлайну в онлайн як вони є. Це для покупця ми намагаємося зробити нове середовище схожим на звичне. А сама компанія та її співробітники мають чітко розуміти відмінності онлайну від офлайну, вчитися працювати в новому середовищі й адаптувати під нього свої процеси. У реальному магазині будь-який огріх продавця можна згладити людським спілкуванням і участю. В онлайні це практично неможливо: людині щось не сподобалося — вона не розбиратиметься, закриє ваш сайт і піде на інший. У реальному магазині відвідувач — УЖЕ практично клієнт, особливо якщо він приміряв взуття, узяв коробку й пішов на касу. В онлайні він може «відвалитися» будь-якої миті, особливо якщо замовлення, оплата й доставка рознесені в часі. Щоб не втратити клієнта, цей час потрібно максимально скоротити або чимось зайняти — пам'ятаєте історію про SMS-супровід?

Як швидко й з найменшими витратами запустити e-commerce платформу

• Розставляємо пріоритети: розділяємо функціонал на основний і додатковий і включаємо в перший реліз лише той, без якого платформа працювати не зможе.
• Викладаємо перший реліз платформи якнайшвидше й доопрацьовуємо її за реальним зворотним зв'язком.
• Шукаємо розумний баланс між ступенем автоматизації та ручною працею — так ми уникаємо подорожчання й затягування строків розробки.
• Маркетингові акції в онлайні реалізуємо точно за такою самою механікою, як вони зроблені в офлайні: покупець має бачити, що в новому для нього каналі всі акції працюють так, як він звик.
• Одразу вибудовуємо систему комунікацій: історія кожного доопрацювання платформи має простежуватися, усі учасники проєкту повинні мати можливість бачити статус задач і обмінюватися інформацією.
• Одразу й правильно класифікуємо запити, що надходять, щоб відділяти окремі випадки від покращень, які справді будуть корисні всій системі.

Результати

INTERTOP — найбільший взуттєвий ритейлер, безумовний лідер ринку, що має понад 200 магазинів в Україні та Казахстані. Мережа працює з 1994 року, відома якісним взуттям провідних світових брендів і активною роботою з аудиторією, тому будь-яка її маркетингова акція викликає в покупців активний відгук і серйозний стрибок продажів. Через рік після перезапуску сайту та старту мультиканальних продажів:

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

Активна фаза розробки — 7 осіб; через рік у розробці залишилося 2 особи, у підтримці — 3. Було налагоджено процедури планування та формулювання задач, контроль за строками їх виконання, тестування й моніторинг серверів.

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