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