Интеграции доставки 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 — технический справочник для оценки пользовательского рабочего процесса отслеживания.