Інтеграції доставки Bigcommerce: варіанти тарифів, етикеток і відстеження

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

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

Що насправді робить кожна інтеграція доставки

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

Рівень інтеграції	Основна відповідальність	Що потрібно перевірити
Тарифи під час оформлення	Визначення способів доставки та вартості, які бачать покупці.	Місця відправлення, місця призначення, дані про товари, доступність послуг і резервна поведінка.
Етикетки та виконання замовлень	Перетворення замовлень на відправлення та створення документів, необхідних для відправлення.	Облікові записи перевізників, вибір упаковки, сумісність із принтером і зворотний запис даних про відправлення.
Відстеження після покупки	Збір подій доставки та забезпечення доступу до інформації про перебіг відправлення.	Отримання номера відстеження, ідентифікація перевізника, доставка оновлень і обробка винятків.

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

Обирайте тип інтеграції відповідно до робочого процесу

Використовуйте налаштування доставки платформи, якщо правила прості

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

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

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

Використовуйте готову інтеграцію для повторюваної роботи з виконання замовлень

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

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

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

Використовуйте власне підключення, коли інша система відповідає за виконання замовлень

Власна інтеграція може бути доцільною, коли система керування замовленнями, складська платформа або сторонній логістичний оператор уже контролює відправлення. У такій схемі BigCommerce може бути каналом продажів, а не операційним джерелом істини для кожної дії, пов’язаної з доставкою.

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

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

Тарифи: узгодьте обіцянку під час оформлення з операцією доставки

Інтеграція тарифів має створювати пропозицію доставки, яку ви можете виконати, а не просто повертати число. Перед тестуванням постачальників задокументуйте дані про місце відправлення, місце призначення, товар і упаковку, які визначають доступність послуги та її вартість.

• Місця відправлення: Який склад або партнер із виконання замовлень відправлятиме замовлення?
• Дані про товари: Чи точні ваги й розміри та чи узгоджені одиниці вимірювання?
• Упаковка: Чи використовує розрахунок окремі товари, вибрану коробку або орієнтовну упаковку?
• Місця призначення: Що відбувається з віддаленими районами, абонентськими скриньками та місцями за межами вашої зони обслуговування?
• Комерційні правила: Чи стягуватимете ви розраховану суму, субсидуватимете доставку або застосовуватимете рекламний поріг?

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

Також визначте поведінку в разі помилки. Якщо запит тарифу не вдається виконати, чи має оформлення показати налаштовану альтернативу, видалити відповідний спосіб або зупинити замовлення? Правильний вибір залежить від того, чи може ваша команда виконати альтернативний варіант. Резервна вартість, яка приймає замовлення, неможливе для відправлення, не є успішним відновленням.

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

Етикетки: оцінюйте повний цикл відправлення

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

Використовуйте такі критерії приймання:

1. Імпорт замовлень: Переконайтеся, що правильні замовлення стають доступними для виконання, а зміни обробляються передбачувано.
2. Створення упаковки: Протестуйте одну посилку, кілька посилок і замовлення, у якому відправляється лише частина товарів.
3. Вибір послуги: Перевірте, як спосіб, обраний покупцем під час оформлення, відповідає послузі, придбаній працівниками складу.
4. Друк: Переконайтеся, що розмір етикетки, формат файлу та параметри друку працюють із фактичним обладнанням складу.
5. Зворотний запис відправлення: Перевірте, що правильна інформація про відстеження та відправлені товари потрапляють до замовлення BigCommerce.
6. Повторний друк і анулювання: Визначте, як працівники уникатимуть повторних покупок і як оброблятимуть невикористані етикетки відповідно до чинних правил постачальника.

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

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

Відстеження: відрізняйте записи про відправлення від видимості доставки

Запис номера відстеження в замовленні вирішує проблему ведення обліку. Збір подальших подій від перевізника вирішує проблему видимості. Вашому бізнесу можуть знадобитися обидві функції, але їх слід оцінювати окремо.

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

Для рівня відстеження під керуванням розробників варто оцінити 17TRACK Tracking API. Його офіційна документація API є основою для оцінювання реєстрації відстеження та доставки подій у власному робочому процесі. Це сценарій використання для відстеження, а не заміна розрахунку тарифів під час оформлення або придбання етикеток.

Не припускайте, що доступність API означає наявність готового конектора BigCommerce. Визначте, як дані про відправлення передаватимуться з вашого магазину або системи виконання замовлень до служби відстеження, як оновлення доходитимуть до місця призначення та хто підтримуватиме підключення.

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

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

Порівнюйте загальну вартість, не покладаючись на рекламну ціну

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

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

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

Проведіть невеликий наскрізний пілотний тест перед переходом

Найнадійніший метод вибору — контрольований пілотний тест із реалістичними замовленнями. Додайте звичайну внутрішню посилку, замовлення з кількома товарами, розділене відправлення та будь-який міжнародний або незвичайний тип відправлення, важливий для вашого бізнесу.

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

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

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

Поширені запитання

Чи потрібні мені окремі інтеграції для тарифів, етикеток і відстеження?

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

Чи змінить інтеграція етикеток тарифи доставки під час оформлення автоматично?

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

Чи можу я підключити власні облікові записи перевізників?

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

Чи може 17TRACK замінити інструмент BigCommerce для етикеток?

Tracking API слід оцінювати для забезпечення видимості відстеження, а не як заміну придбанню етикеток. Власний робочий процес може передавати інформацію про відправлення до служби відстеження, залишаючи розрахунок тарифів під час оформлення та створення етикеток системам, відповідальним за ці завдання.

Чому після отримання номера відстеження клієнт може не бачити жодного руху?

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

Джерела

• BigCommerce App Marketplace — офіційна відправна точка для пошуку готових інтеграцій і перевірки окремих описів.
• BigCommerce Developer Documentation — офіційний довідник для перевірки вимог до інтеграції платформи та деталей реалізації API.
• 17TRACK Tracking API — офіційний опис продукту для варіанта API відстеження, розглянутого в цьому посібнику.
• 17TRACK API Documentation — технічний довідник для оцінювання власного робочого процесу відстеження.