Як власнику інтернет-магазину вийти з щоденної ручної роботи
Магазин продає через сайт, Prom.ua і Rozetka, відправляє посилки Новою поштою та Укрпоштою, приймає оплати кількома способами. У результаті багато питань щодня сходяться на власнику: він сам розбирає ТТН, ціни, статуси замовлень і пише в підтримку кожного сервісу. Ця стаття про те, як передати цю роботу команді за простими правилами, щоб власник менше втручався в щоденні операційні питання.
Ця стаття доповнює посібник із технічного налаштування обліку для інтернет-магазину. Там про сервер, базу даних і синхронізації. Тут про те, як організувати роботу людей.
Знайомі ситуації
Перевірте, скільки пунктів із цього списку про ваш магазин.
- власник сам пише в підтримку маркетплейсів, перевізників, банку і програми з кожного питання;
- проблеми виявляються на замовленнях живих клієнтів, бо ніхто не перевіряє роботу заздалегідь;
- збій в одному каналі продажів зачіпає обробку всіх замовлень;
- менеджери чекають рішення власника навіть у простих ситуаціях;
- ті самі помилки повторюються, бо після кожного випадку ніхто не записує нове правило;
- звернення в підтримку пишуться без даних: без номера замовлення, часу й опису, що саме пішло не так.
Кожен пункт окремо виглядає як дрібниця. Разом вони означають одне: усі нестандартні питання магазину проходять через одну людину. Це забирає у власника багато часу щодня. І чим більше замовлень, тим більше цього часу потрібно.
Чому так виходить
Коли в магазину один канал продажів, часто здається, що окремі правила не потрібні: власник бачить кожне замовлення й тримає процес у голові. І це справді працює.
Потім додається сайт, Prom, Rozetka, друга служба доставки, оплати частинами. У кожного сервісу свої статуси, свої правила оплат, свої вимоги до даних одержувача. Типовий український інтернет-магазин щодня має справу з пʼятьма-сімома зовнішніми сервісами: маркетплейси, перевізники, банк, платіжні сервіси, хостинг сайту, програма обліку.
Магазин виріс, а звичка «все тримати в голові» залишилася. Письмових правил немає, тому кожне нестандартне питання йде до власника. А власник із кожним питанням іде в підтримку чергового сервісу. Підтримка сервісу може допомогти у своїй частині: маркетплейс — із кабінетом, перевізник — із доставкою, розробник програми — з налаштуваннями, діагностикою та консультаціями в межах умов технічної підтримки. Але рішення всередині магазину — кого призначити відповідальним, за якою ціною відвантажувати, коли зупинити замовлення — може ухвалити лише сам бізнес.
Крок перший: призначте відповідального за онлайн-продажі
Потрібна одна людина, яка відповідає за щоденну роботу всіх каналів продажів. Це не обовʼязково нова посада. У невеликому магазині цю роботу бере на себе старший менеджер або адміністратор. Головне — записати, за що саме ця людина відповідає:
- налаштування обміну з сайтом і маркетплейсами;
- щоденний перегляд журналу синхронізації та проблемних замовлень;
- перевірка цін і націнок у каналах;
- правила створення ТТН і звірка відправлень;
- звірка оплат і розбір незрозумілих платежів;
- правила роботи менеджерів і навчання новеньких;
- перевірка роботи після оновлень програми та змін на маркетплейсах;
- листування з підтримкою сервісів: коротко, з фактами.
Після цього власник отримує від відповідального короткі підсумки. У деталі власник занурюється лише тоді, коли питання справді велике. Про це нижче.
Хто що робить: проста таблиця
Щоб відповідальний не перетворився на ще одну людину, яка тягне все сама, розпишіть основні дії по людях. Приклад:
| Що відбувається | Менеджер | Відповідальний | Фінансист | Комірник | Власник |
|---|---|---|---|---|---|
| Нове замовлення | обробляє | стежить за правилами | — | — | бачить підсумки |
| Клієнт змінив замовлення | вносить зміни й позначає | перевіряє ціну | — | — | лише якщо ризик великий |
| ТТН і відправлення | створює | стежить за помилками | — | перевіряє комплектацію | — |
| Оплати | бачить статус | розбирає незрозумілі | звіряє надходження | — | бачить борги й післяплати |
| Збій у роботі | записує факт | веде журнал і заявки | рахує суму ризику | підтверджує наявність товару | вирішує великі питання |
Принцип простий: у кожної дії є виконавець і той, хто перевіряє. Власник зʼявляється в таблиці лише там, де підсумок або великий ризик. Складіть свою версію під свою команду й тримайте її на одній сторінці.
Як обробляється замовлення: запишіть основні кроки
Далі опишіть на одній сторінці шлях звичайного замовлення. Це і є головний робочий документ для менеджерів.
- Замовлення завантажилося в програму. Менеджер бачить його у списку нових.
- Менеджер телефонує клієнту протягом визначеного часу. Підтверджує товари, доставку та оплату.
- За підтвердженим замовленням створюється рахунок за встановленим правилом.
- Якщо оплата наперед — менеджер чекає надходження грошей. Якщо післяплата — готує відправлення.
- Створюється ТТН із даних замовлення. Менеджер перевіряє одержувача, відділення й контроль оплати.
- Після відправлення номер ТТН передається в канал продажу, статус замовлення оновлюється.
- Оплата звіряється з рахунком. Незрозумілі платежі йдуть фінансисту.
Біля кожного кроку допишіть три речі: хто робить, за який час, що робити, якщо крок не вийшов. Третя частина найважливіша — саме вона знімає питання з власника.
Нестандартні ситуації: короткі правила
Гроші й час найчастіше втрачаються не на звичайних замовленнях, а на нестандартних ситуаціях. Для кожної типової ситуації запишіть коротке правило.
| Ситуація | Правило |
|---|---|
| Клієнт після дзвінка змінив склад замовлення | менеджер додає товар, перевіряє ціну каналу, ставить позначку; перед відправленням рахунок дивиться старший |
| Замовив один, а отримує інший | менеджер звіряє дані одержувача з кабінетом маркетплейсу до створення ТТН |
| Оплата ще не зарахувалася від сервісу маркетплейсу | замовлення чекає в окремому стані; відправляти після зарахування або за письмовим правилом для постійних клієнтів |
| Замовлення є, а товару на залишку немає | менеджер діє за правилом: запропонувати заміну, почекати постачання або скасувати; залишки в каналах перевіряє відповідальний |
| Ціна в замовленні не така, як очікувалося | замовлення не відправляється, поки не перевірили; випадок записується в журнал збоїв |
| ТТН не створюється або не передається в канал | менеджер працює за тимчасовим рішенням; відповідальний збирає факти й пише заявку сервісу |
Правила навмисно короткі. Мета проста: менеджер у незвичній ситуації знає, що робити, і не смикає власника.
Каталог товарів: домовтеся про порядок
Багато збоїв починається з каталогу. Різні назви одного товару, відсутні фото, незаповнені характеристики, дублікати. Кожна така дрібниця повторюється на сайті, на Prom і на Rozetka, а потім повертається помилками вивантаження і питаннями покупців. Домовтеся про кілька простих речей:
- товар заводиться й редагується лише в програмі обліку; правки напряму на сайті чи маркетплейсі заборонені;
- є конкретна людина, яка заповнює назви, фото, описи й характеристики нових товарів;
- правила назв записані: порядок слів, виробник, артикул, розмір;
- після зміни видів товарів хтось перевіряє, чи не зʼїхали категорії на маркетплейсах;
- помилки вивантаження переглядаються регулярно, за визначеним розкладом;
- для дублікатів і товарів «немає в наявності» є записане правило.
Склад і резерв: щоб не продати те, чого немає
Одне онлайн-замовлення і один покупець у магазині можуть претендувати на останню одиницю товару. Без правил це закінчується продажем відсутньої позиції та скасуванням, яке псує рейтинг на маркетплейсі. Запишіть відповіді на кілька питань:
- коли товар резервується: коли замовлення завантажилося чи коли створили рахунок;
- хто перевіряє, що товар справді є, якщо залишок мінімальний;
- що робити, коли товар числиться в програмі, а на полиці його немає: тимчасово прибрати з продажу, перерахувати цю позицію, записати випадок у журнал;
- хто виправляє пересорт;
- як швидко після продажу в магазині оновлюються залишки на сайті й маркетплейсах і хто за цим стежить;
- хто пропонує клієнту заміну, а хто вирішує скасувати замовлення.
Контроль прибутку: які замовлення зупиняти перед відправленням
Найдорожчі помилки повʼязані з цінами. На сайті й маркетплейсах можуть діяти різні націнки. Коли менеджер вручну міняє склад замовлення, ціна може стати нижчою, ніж планувалося. Захист простий — кілька правил зупинки:
- замовлення, де менеджер міняв склад вручну, отримують окремий стан і не відправляються без перевірки;
- перед відправленням порівнюються ціна на маркетплейсі й ціна в рахунку;
- замовлення з розбіжністю цін чекає, поки розберуться;
- якщо гроші вже втрачені, сума записується в журнал збоїв;
- раз на тиждень відповідальний переглядає замовлення, де заробіток вийшов підозріло малим.
Коли ці перевірки вбудовані у звичайну роботу, вони займають хвилини. Без них про втрачені гроші дізнаються запізно, коли вже нічого не вдієш.
Гроші: шість цифр, які власник бачить щодня
Оплати приходять різними шляхами і в різний час: передоплати, зарахування від маркетплейсів, реєстри перевізників за післяплатами, повернення. Власнику не потрібно розбирати кожен платіж. Достатньо короткого щоденного зведення з шести цифр:
- сума неоплачених рахунків;
- сума післяплат у дорозі;
- сума незрозумілих платежів, які чекають розбору;
- повернення за період;
- кількість замовлень, зупинених через розбіжність ціни;
- кількість замовлень із ризиком втратити заробіток.
Ці цифри готує фінансист або відповідальний. Поки вони в межах звичного, власник у деталі не йде. Цифра відхилилася — це сигнал подивитися глибше.
Журнал збоїв: записуйте, що зламалося
Коли збій описаний словами «щось не працює», його важко перевірити. Для перевірки потрібні конкретні дані: де сталося, з яким замовленням, о котрій годині, що очікували і що вийшло насправді. Журнал збоїв — це проста таблиця, куди відповідальний записує кожен випадок.
| Що записати | Приклад |
|---|---|
| Дата й час | коли сталося і коли помітили |
| Де | сайт, маркетплейс, доставка, оплата |
| Замовлення | номер замовлення або рахунку |
| Що сталося | що очікували і що вийшло, знімок екрана |
| Скільки грошей під ризиком | сума або кількість зачеплених замовлень |
| Чи повторюється | один раз чи регулярно |
| Тимчасове рішення | як менеджери працюють, поки питання не закрите |
| Стан | передано сервісу, у роботі, вирішено, перевірено |
Журнал дає три речі. Менеджери знають, куди повідомляти про збій, і робота не зупиняється. Підтримка сервісу — маркетплейсу, перевізника чи програми — отримує заявку з фактами і може швидко її перевірити. Власник бачить реальну картину: скільки збоїв, скільки грошей під ризиком, що повторюється.
Одна форма заявки для всіх сервісів
Заявка, зібрана із журналу, пишеться швидко. І підтримці будь-якого сервісу — маркетплейсу, перевізника чи програми — з нею простіше: не треба десять разів перепитувати деталі. Що вказати:
Де сталося: канал або сервіс. Номер замовлення чи рахунку. Час. Що очікували. Що вийшло насправді. Знімок екрана або текст помилки. Чи повторюється. Скільки грошей під ризиком. Як працюєте зараз, поки питання відкрите. І головне — що просите: перевірити, налаштувати чи порадити.
Останній пункт найкорисніший. Коли в заявці написано, чого саме ви очікуєте, підтримці простіше спрямувати її потрібному фахівцю.
Коли питання передається власнику
Щоб власник не повертався в кожну дрібницю, домовтеся письмово, у яких випадках відповідальний іде до нього. Приклади:
- збій повторився три і більше разів за день;
- канал продажів не приймає замовлення понад годину;
- ТТН масово не створюються або не передаються;
- розбіжність між оплатами й обліком більша за домовлену суму;
- проблема зачіпає понад десять відсотків денних замовлень;
- можлива втрата грошей більша за домовлену суму.
Конкретні суми кожен магазин ставить під свій обсяг. Головне, щоб вони були записані. Тоді все, що нижче порога, вирішується без власника.
Перевірка після оновлень і змін: не тестуйте на клієнтах
Програма оновлюється, маркетплейси й перевізники змінюють правила. Якщо після змін ніхто нічого не перевіряє, першим перевіряльником стає клієнт зі своїм замовленням. Простіше тримати короткий список перевірок, який відповідальний проходить після оновлення програми або помітної зміни на маркетплейсі:
- замовлення з маркетплейсу з націнкою каналу;
- замовлення з маркетплейсу без оплати;
- замовлення з оплатою через сервіс маркетплейсу;
- замовлення, у яке додали товар після дзвінка;
- замовлення, де замовник і одержувач різні;
- ТТН із післяплатою і контролем оплати;
- ТТН другого перевізника;
- часткова оплата рахунку;
- скасування замовлення з передачею статусу;
- зміна статусу замовлення на маркетплейсі;
- повторний обмін після помилки;
- оновлення залишку в усіх каналах після продажу.
У невеликій команді такий прохід може займати близько години, якщо тестові товари й доступи підготовлені заздалегідь. Ця година дешевша, ніж розбір проблем на живих замовленнях.
Сервіс змінив правила: два шляхи
Маркетплейси, перевізники й банки змінюють правила тоді, коли їм потрібно. Магазин на це не впливає. Але магазин повністю контролює, як він на це реагує.
Різниця у двох кроках. Спершу перевірити самим на тестовому замовленні, що саме змінилося. Потім дати менеджерам тимчасове рішення, щоб відправлення не зупинялися. І лише після цього писати заявку сервісу — уже з фактами. Так магазин не залежить від швидкості чужої відповіді.
Що переглядати щодня, щотижня і щомісяця
Правила працюють, коли в них є розклад. Без розкладу перевірки відбуваються лише після скарг. З розкладом відповідальний знає, що і коли дивиться, а власник — коли отримує зведення.
| Коли | Що дивитися |
|---|---|
| Щодня | журнал синхронізації, нові проблемні замовлення, незрозумілі оплати, відправлення без статусу ТТН |
| Щотижня | журнал збоїв, замовлення з малим заробітком, помилки, що повторюються, оновлення правил |
| Щомісяця | витрати на супровід і послуги, які канали продають краще, стан каталогу, список побажань до сервісів і програми |
У налагодженій роботі щоденний перегляд може займати до пів години, якщо відповідальні і порядок перевірки вже визначені. Щотижневий і щомісячний — це коротка розмова або зведення, після яких оновлюються правила.
Супровід програми: планова витрата, як звʼязок чи банк
Магазину з одним каналом продажів програма обліку може роками не потребувати сторонньої допомоги. Магазин із сайтом, двома маркетплейсами, двома перевізниками й банком влаштований складніше: обміни, оновлення і зміни зовнішніх сервісів час від часу потребують участі фахівців.
Тому супровід програми для такого магазину розумно закладати в бюджет як регулярну витрату — так само, як звʼязок чи банківське обслуговування. Коли супровід у бюджеті, кожне технічне питання стає плановою задачею з виконавцем. Коли не в бюджеті, кожне питання починається з погодження, хто платить, і саме на цьому втрачається час, який можна було витратити на перевірку або налаштування.
Хто за що відповідає серед зовнішніх сервісів
У кожного сервісу своя зона. Коли команда це розуміє, заявка одразу йде за правильною адресою, і ніхто не чекає від одного сервісу рішень, які залежать від іншого.
| Хто | За що відповідає | Приклад звернення |
|---|---|---|
| Маркетплейс | робота майданчика, кабінет, правила розміщення, комісії, виплати | замовлення не видно в кабінеті |
| Перевізник | доставка, відділення, реєстри післяплат, тарифи | посилка затрималася, реєстр не зійшовся |
| Банк, платіжний сервіс | зарахування грошей, виписки, еквайринг | оплата списана, гроші не надійшли |
| Розробник програми обліку | робота програми, налаштування, перевірка й опрацювання підтверджених помилок | сценарій у програмі працює некоректно |
| Хостинг, розробник сайту | доступність сайту, роботи на боці сайту | сайт не приймає замовлення |
| Сам магазин | ціни, заробіток, правила для менеджерів, якість даних, рішення щодо спірних замовлень | відправляти чи ні спірне замовлення |
Для програми обліку порядок звернень — що є послугою, що перевіркою, що помилкою, а що побажанням — детально описаний у посібнику з технічного налаштування. Схожі правила підтримки є і в маркетплейсів, і в перевізників. Заявка з фактами скрізь проходить швидше.
Перевірте себе: короткий список
- є відповідальний за онлайн-продажі, і його обовʼязки записані;
- дії команди розписані по людях: хто робить, хто перевіряє;
- шлях звичайного замовлення описаний на одній сторінці;
- для нестандартних ситуацій є короткі записані правила;
- є відповідальні за каталог і за склад;
- замовлення з ручними змінами й розбіжністю цін зупиняються перед відправленням;
- власник щодня бачить коротке зведення із шести цифр;
- ведеться журнал збоїв із сумами під ризиком;
- заявки до сервісів пишуться за однією формою;
- записано, у яких випадках питання передається власнику;
- є список перевірок після оновлень і змін;
- визначено, що переглядається щодня, що щотижня, що щомісяця;
- витрати на супровід програми заплановані за потреби;
- після кожного вирішеного збою правило роботи оновлюється.
Часті запитання
Чи потрібно наймати окрему людину?
На обсягах до кількох десятків замовлень на день зазвичай ні. Обовʼязки відповідального бере на себе старший менеджер або адміністратор, і на них закладається частина робочого часу. Окрема посада має сенс тоді, коли розбір нестандартних ситуацій займає більшу частину дня.
Навіщо правила, якщо програма і так усе автоматизує?
За відповідних налаштувань програма веде звичайний потік: завантажує замовлення, створює рахунки, формує ТТН із даних замовлення, допомагає звіряти оплати. Але є рішення, які програма ухвалити не може: відправляти чи ні спірне замовлення, за якою ціною погодити заміну, що робити з незрозумілою оплатою. Для таких рішень і потрібні записані правила. Програма і правила працюють разом.
Що робити, коли збій справді на боці сервісу?
Збої трапляються в будь-якого сервісу: у маркетплейсу, перевізника, банку чи програми. Порядок дій однаковий: дати менеджерам тимчасове рішення, написати заявку з фактами, тримати випадок у журналі до вирішення. Заявка з номером замовлення, знімком екрана й описом, що очікували і що вийшло, зазвичай зменшує кількість уточнень і допомагає швидше перейти до перевірки. Щодо програми перевірка визначає, чи це підтверджена помилка для передачі в розробку.
З чого почати, якщо нічого з цього ще немає?
Три перші кроки: призначити відповідального, описати шлях замовлення на одній сторінці, завести журнал збоїв. Це зазвичай можна зробити без зупинки роботи. У невеликій команді часто вистачає одного-двох тижнів, якщо у відповідального є час і повноваження. Решту — правила для нестандартних ситуацій, контроль цін, список перевірок — додавайте поступово, починаючи з того, що коштує найдорожче.
Висновок
Інтернет-магазин із кількома каналами продажів складається з двох частин. Технічна частина — сервер, база, налаштування, обміни — описана в окремому посібнику. Друга частина — люди і правила: відповідальний, записаний шлях замовлення, правила для нестандартних ситуацій, журнал збоїв, перевірки після змін і зрозумілі зони сервісів. Коли є обидві частини, автоматизація дає повний результат.
Перевірити себе просто. Якщо власник сам розбирає більшість питань щодо ТТН, цін і статусів, варто почати з правил і відповідального. Це поступово зменшує кількість ручних розборів і звільняє власнику час на розвиток магазину.
Хочете узгодити налаштування Торгсофт із порядком роботи вашого магазину? Фахівці Торгсофт допоможуть налаштувати обробку замовлень, стани, ТТН, оплати й ролі користувачів у межах можливостей програми та чинних умов технічної підтримки.
Отримати консультацію
Повернутися до попереднього кроку