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