Satınalmadan sonrakı texnoloji yığın: İzləmə, qaytarışlar, dəstək və onların necə əlaqələndiyi

Açıqdan sonrakı texnologiya steki göndərişlərin izlənməsini, qaytarmaların idarə edilməsini, müştəri dəstəyini və sifariş və ödəniş qeydlərini saxlayan sistemləri birləşdirir. Elektron ticarət komandaları üçün məqsəd hər tapşırıq üçün ayrıca tətbiq almaq deyil. Məqsəd çatdırılma hadisələrinin, müştəri sorğularının və geri ödəniş qərarlarının konteksti itirmədən və ziddiyyətli əməliyyatlara səbəb olmadan sistemlər arasında ötürülməsini təmin etməkdir.

Bu təlimat hər təbəqənin nəyə cavabdeh olmalı olduğunu, məlumatın onlar arasında necə axmalı olduğunu və steki genişləndirməzdən əvvəl əlaqələrin necə sınaqdan keçirilməli olduğunu izah edir. Ən faydalı başlanğıc nöqtəsi vahid müştəri səyahətidir: sifariş göndərilir, nəsə dəyişir, müştərinin köməyə ehtiyacı olur və kimsə bundan sonra nə baş verəcəyinə qərar verməlidir.

Tətbiqlər siyahısına deyil, məsuliyyətlərə əsaslanın

İzləmə aləti göndərişin gedişatını bildirə bilər, lakin göndəriş yeniləməsi tam sifariş qeydi deyil. Qaytarma portalı sorğu toplaya bilər, lakin bu sorğu geri ödənişin həyata keçirildiyinə sübut deyil. Dəstək agenti istisnanı təsdiqləyə bilər, lakin qərar hələ də onu icra edən sistemə çatmalıdır.

Bu fərqlər vacibdir, çünki əlaqələndirilmiş sistemlər eyni məlumatı göstərə bilər, lakin onu dəyişdirmək üçün eyni səlahiyyətə malik olmaya bilər. Hər bir qeyd üçün səlahiyyətli sistemi təyin edin və digər sistemlərin ona istinad etməsini təmin edin.

Bu, beş ayrı məhsuldan istifadə tələbi deyil, tövsiyə olunan sahiblik modelidir. Bir platforma bir neçə məsuliyyəti əhatə edə bilər. Əsas sınaq hər mühüm statusun aydın sahibinin olub-olmaması və digər sistemlərin tələb olunan əməliyyatla tamamlanmış əməliyyatı fərqləndirə bilməsidir.

İzləmə kommersiya qərarları vermədən göndərişin gedişatını izah etməlidir

İzləmə təbəqəsi daşıyıcının fəaliyyətini müştərinin sifarişi ilə əlaqələndirir. O, müştərilərə bağlamalarının harada olduğunu anlamağa və əməkdaşlara göndərişin diqqət tələb etdiyi halları müəyyən etməyə kömək etməlidir. Poçt göndərişləri üçün poçt izləmə bu görünürlük təbəqəsinin bir hissəsidir; daha geniş arxitektura bir neçə bağlaması və ya müxtəlif daşıyıcıları olan sifarişləri də nəzərə almalıdır.

Sifarişləri və göndərişləri ayrı modelləşdirin. İki bağlamalı sifarişdə bir bağlama çatdırılmış, digəri isə hələ yolda ola bilər. İlk çatdırılma hadisəsindən sonra bütün sifarişi çatdırılmış kimi işarələmək yanıltıcı bildirişlərə, yanlış dəstək cavablarına və hansı məhsulların qaytarıla biləcəyi ilə bağlı çaşqınlığa səbəb ola bilər.

İlkin hadisəni sadələşdirilmiş statusla birlikdə saxlayın

“Yoldadır” kimi müştəriyə göstərilən statusu oxumaq daşıyıcının hadisə lentindən daha asandır. Bununla belə, dəstək komandaları problemi araşdırmaq üçün ilkin hadisə mətninə, məkana və vaxt möhürünə ehtiyac duya bilər. Mümkün olduqda hər iki görünüşü qoruyun və daşıyıcının hadisənin baş verdiyini bildirdiyi vaxtla sisteminizin onu qəbul etdiyi vaxtı fərqləndirin.

İzləmə istisnası adətən nəzərdən keçirmə və ya müəyyən edilmiş iş axınını başladmalıdır, avtomatik olaraq geri ödənişə icazə verməməlidir. Gecikmə, çatdırılma cəhdi və çatdırılmış kimi bildirilən, lakin alınmayan bağlama fərqli tədbirlər tələb edir. Qərarı satıcının siyasəti və araşdırma prosesi müəyyən etməlidir.

Bildirişlərə cavabdehliyi təyin edin

Hər mesajı hansı sistemin göndərdiyini müəyyənləşdirin. Elektron ticarət platforması, izləmə tətbiqi və dəstək avtomatlaşdırması çatdırılma yeniləmələrini birlikdə göndərərsə, müştəri təkrarlanan və ya ziddiyyətli mesajlar ala bilər. Tətik, göndərən, auditoriya, susdurma şərtləri və təyinat linkini göstərən bildiriş xəritəsi saxlayın.

Məsələn, göndəriş gecikməsi mesajı əvəzedici məhsul həqiqətən təsdiqlənməyibsə, onu vəd etməməlidir. Onun məqsədi sadəcə son statusu izah etmək və yardım almaq üçün yol təqdim etmək ola bilər.

Qaytarmalar məhsul səviyyəsində kontekst və ayrıca maliyyə statusu tələb edir

Qaytarma yalnız izləmə nömrəsi ilə deyil, məhsul və siyasət qərarı ilə başlayır. Qaytarma təbəqəsi nəyin satın alındığını, hansı miqdarların hələ qaytarıla biləcəyini və əvvəlki qaytarma və ya geri ödənişin sorğuya təsir edib-etmədiyini bilməlidir.

Avtomatlaşdırmanı tətbiq etməzdən əvvəl qaytarmanı irəlilədən hadisələri müəyyənləşdirin. Praktik iş axını sorğunun göndərilməsi, sorğunun təsdiqlənməsi, bağlamanın təhvil verilməsi, bağlamanın alınması, yoxlamanın tamamlanması və geri ödənişin tələb edilməsini fərqləndirə bilər. Faktiki mərhələləriniz biznesin iş üsuluna uyğun olmalıdır.

Bu mərhələləri vahid “qaytarıldı” etiketi altında birləşdirməyin. Qaytarılan bağlama üçün daşıyıcının çatdırılma hadisəsi anbar əməkdaşlarının içindəkiləri yoxladığını özü-özlüyündə təsdiqləmir. Eyni şəkildə, geri ödəniş sorğusu ödəniş sisteminin geri ödənişi uğurla emal etdiyini göstərmir.

• Qismən qaytarmalar üçün: yalnız sifariş cəmini deyil, sətir məhsulu identifikatorlarını və miqdarları mübadilə edin.
• Dəyişdirmələr üçün: ehtiyatı kimin ayıracağını, əvəzedici sifarişi kimin yaradacağını və qiymət fərqini kimin idarə edəcəyini müəyyən edin.
• Erkən geri ödənişlər üçün: uyğunluq hadisəsini, risk yoxlamalarını, təsdiq səlahiyyətini və istisna prosesini göstərin.
• Siyasət istisnaları üçün: istisnanı kimin təsdiqlədiyini və bunun hansı sonrakı əməliyyata icazə verdiyini qeyd edin.

Uyğunluğu müəyyən etmək üçün dərc olunmuş siyasətinizdən və tətbiq olunan öhdəliklərdən istifadə edin. Proqram konfiqurasiyası bu qərarları icra etməli, səssizcə siyasətin özünə çevrilməməlidir.

Dəstək istisnalar üçün qərar təbəqəsidir

Dəstək iş sahəsi agentlərin sifarişi bir neçə panel arasında yenidən qurmasına ehtiyac qalmadan işi həll etməsi üçün kifayət qədər konteksti bir araya gətirməlidir. Bu, hər qeydin hər müraciətə kopyalanması demək deyil.

Faydalı sifariş panelinə göndəriş əlaqələri, ən son müvafiq izləmə hadisələri, açıq qaytarmalar, geri ödəniş nəticələri və əvvəlki qərarlar daxildir. O, həmçinin məlumatın sonuncu dəfə nə vaxt yeniləndiyini göstərməlidir. Vaxt möhürü olmadan göstərilən köhnə status aktual görünə və agentin yanlış məsləhət verməsinə səbəb ola bilər.

Oxuma girişini əməliyyat icazələrindən ayırın. Bir çox agent geri ödəniş tarixçəsinə baxmalı ola bilər; lakin daha az sayda agent geri ödəniş vermək və ya qaytarma uyğunluğunu dəyişmək səlahiyyətinə malik olmalıdır. Pul və ya inventara təsir edən əməliyyatların audit izi və təkrarlanmanın qarşısını alan qoruyucuları olmalıdır.

İşin tələb etdiyi qaydada müraciətləri yönləndirin. Son vaxtlar hərəkət etməyən göndəriş logistika araşdırması tələb edə bilər. Rədd edilmiş geri ödəniş əməliyyatı ödəniş əməliyyatları komandasına yönləndirilə bilər. Gözlənilməz məzmunla alınmış qaytarma anbar yoxlaması tələb edə bilər. Müraciət kateqoriyası yalnız müəyyən edilmiş sahibə və növbəti addıma aparırsa faydalıdır.

Sistemlər necə əlaqələndirilir: bir istisnanı əvvəldən sona qədər izləyin

Ayrı bağlamalarda göndərilmiş iki məhsuldan ibarət nümunəvi sifarişi nəzərdən keçirək. Bir bağlama çatır, digərində isə çatdırılma istisnası yaranır. Müştəri dəstəyə müraciət edir və daha sonra çatdırılmış məhsulu qaytarır.

1. Sifariş sistemi əlaqələri yaradır. Hər sətir məhsulu düzgün göndərişlə əlaqələndirilir. Dəstək çatdırılmayan məhsulun çatdırılmış bağlamada olmadığını görə bilir.
2. İzləmə təbəqəsi istisnanı qəbul edir. O, göndəriş istinadını və hadisə detallarını saxlayır. İş axını bütün sifarişi itmiş hesab etmək əvəzinə araşdırma yaradır və ya yeniləyir.
3. Dəstək işi nəzərdən keçirir. Agent müvafiq göndərişi yoxlayır və razılaşdırılmış növbəti addımı qeyd edir. Əvəzedici məhsula icazə verilərsə, sifariş sistemi onu yaratmaq üçün ayrıca təlimat alır.
4. Müştəri çatdırılmış məhsul üçün qaytarma tələb edir. Qaytarma sistemi məhsulu və miqdarı sifariş və mövcud qaytarma fəaliyyəti ilə müqayisə edir.
5. Anbar qaytarmanı qəbul edir və yoxlayır. Yoxlama nəticəsi yalnız bağlama izləməsindən çıxarılmır, qaytarma qeydinə əlavə edilir.
6. Maliyyə iş axını təsdiqlənmiş qərarı icra edir. Geri ödəniş nəticəsi sistemə yazılır ki, dəstək və müştəriyə göstərilən qaytarma görünüşü təsdiqlə tamamlanmanı qarışdırmasın.

Əlaqələr o zaman uğurlu sayılır ki, hər iştirakçı eyni nəticəni görsün və öz məsuliyyətindən kənar qeydləri üzərinə yazmağa icazəsi olmasın.

Satış nümayişi fərziyyəsi ilə deyil, sınaqla yoxlanmalı inteqrasiya detalları

Paylaşılan identifikatorlar və qeydlərin uyğunlaşdırılması

Sifarişləri, sətir məhsullarını, göndərişləri, qaytarmaları və müraciətləri əlaqələndirmək üçün sabit daxili identifikatorlardan istifadə edin. Yalnız e-poçt ünvanına və ya göstərilən sifariş nömrəsinə güvənməyin. Uyğunlaşdırma qaydalarınız izləmə nömrələrinin daşıyıcı kontekstində şərh edilməsini və müştərinin bir neçə aktiv sifarişinin olmasını nəzərə almalıdır.

Hadisələrin çatdırılması və üzləşdirmə

Dəstəkləndiyi hallarda webhook-lar hadisə baş verdikdə qəbul edən sistemi xəbərdar edə bilər. Lakin onlar çatışmayan, gecikmiş, təkrarlanan və ya ardıcıllıqdan kənar mesajların idarə edilməsi ehtiyacını aradan qaldırmır. Uğursuz çatdırılmaların necə təkrarlandığını və kəsintidən sonra komandanızın hadisələri necə bərpa edə biləcəyini soruşun.

Təkrar emalı təhlükəsiz edin. Məsələn, eyni qaytarma təsdiqinin iki dəfə alınması iki geri ödəniş verməməlidir. Üzləşdirmə işi həmçinin mühüm qeydləri sistemlər arasında müqayisə etməlidir ki, buraxılmış bildiriş qaytarma və ya geri ödənişi daimi olaraq ilişmiş vəziyyətdə saxlamasın.

Autentifikasiya və müştəri məlumatlarının sərhədləri

İzləmə sorğusu, qaytarma sorğusu və agent tərəfindən verilən geri ödəniş müxtəlif giriş səviyyələri tələb edir. Müştərilərin sifarişi görmək və ya dəyişmək səlahiyyətini necə sübut etdiyini, əməkdaş icazələrinin necə təyin olunduğunu və hər əlaqələndirilmiş tətbiqin həqiqətən hansı şəxsi məlumatlara ehtiyac duyduğunu müəyyənləşdirin.

Tətbiq zamanı webhook autentifikasiyasını, etimadnamələrin saxlanmasını, girişin ləğvini, saxlama parametrlərini və audit jurnallarını yoxlayın. Daxili istinad kifayət etdiyi halda tam müştəri qeydlərini jurnallara köçürməyin.

17TRACK arxitekturaya necə uyğun gəlir

17TRACK yönümlü qiymətləndirmə üçün işə uyğun məhsul giriş nöqtəsindən başlayın. istehlakçı izləmə veb-saytı fərdi göndəriş axtarışı üçün uyğundur. Sifariş izləmə tətbiqini qiymətləndirən satıcılar 17TRACK Shopify siyahısına baxa bilərlər. Fərdi əlaqə yaradan komandalar İzləmə API məlumatlarına və API sənədlərinə müraciət edə bilərlər. Qaytarma tələbləri 17RETURNS-ın ayrıca nəzərdən keçirilməsinə daxildir.

Bunlar müvafiq qiymətləndirmə istiqamətləridir, bu təlimatdakı hər əlaqənin hazır şəkildə mövcud olduğuna sübut deyil. İstifadə etməyi planlaşdırdığınız məhsul üçün konkret məlumat sahələrini, dəstəklənən iş axınlarını, icazələri və kommersiya şərtlərini təsdiqləyin. Əlaqəli məhsulların seçilməsinin dəstək müraciətlərini, anbar yoxlamalarını və ya ödəniş nəticələrini avtomatik sinxronlaşdırdığını düşünməyin.

Həqiqi boşluğu aradan qaldıran ən kiçik iş axınını tətbiq edin

Mövcud əməliyyatınızdakı ən bahalı ötürmədən başlayın. Agentlər mütəmadi olaraq göndəriş statusunu əl ilə yoxlayırsa, dəstəkdə izləmə kontekstinə üstünlük verin. Müştərilər qaytarmanın alınıb-alınmadığını və ya geri ödənilib-ödənilmədiyini bilmirlərsə, qaytarmadan anbara, oradan da ödənişə qədər olan əlaqəyə üstünlük verin.

Başqa tətbiq almadan əvvəl elektron ticarət platformanızda və dəstək sisteminizdə artıq mövcud olan imkanları xəritələndirin. Müəyyən edilmiş boşluğu həll edirsə, ixtisaslaşmış alət əlavə edin və iş axınının hamısını yoxlayın; onu yalnız müştəriyə görünən səhifəyə görə qiymətləndirməyin.

Faydalı qəbul sınağına aşağıdakılar daxil olmalıdır:

• Bir neçə göndərişə bölünmüş sifariş.
• Daha yeni hadisədən sonra gələn izləmə yeniləməsi.
• Maliyyə əməliyyatını təkrarlamamalı olan təkrarlanan hadisə.
• Eyni sifariş üzrə əvvəlki geri ödənişlə qismən qaytarma.
• Dəstəyə görünən olaraq qalan uğursuz geri ödəniş.
• Bərpa ilə nəticələnən müvəqqəti inteqrasiya kəsintisi.
• Qeydə alınmış səbəblə normal iş axınını dəyişən əl ilə verilmiş istisna.

Hər uğursuz sınağa sahib təyin edin və inteqrasiya əlçatan olmadıqda əməkdaşların necə işləyəcəyini müəyyənləşdirin. Əl ilə ehtiyat proses dizaynın bir hissəsidir, avtomatlaşdırmanın uğursuzluğunun etirafı deyil.

Ötürmələr üzrə nəticələri ölçün

Göndərilmiş sifarişə düşən çatdırılma ilə bağlı müraciətləri, qaytarma emalı müddətini, həll olunmamış inteqrasiya xətalarını və geri ödənişin təsdiqi ilə icrasının təsdiqlənməsi arasındakı vaxtı izləyin. Hər metrik göstəricini dəqiq müəyyənləşdirin. Məsələn, komandanın nəticəyə uyğun tədbir görə bilməsi üçün qaytarma tranzit vaxtını anbar emalı vaxtından ayırın.

Mümkün olduqda oxşar dövrləri və müştəri qruplarını müqayisə edin. Dəstək müraciətlərinin azalması avtomatik olaraq yaxşılaşma demək deyil, çünki müştərilər yardım almaq imkanını da itirmiş ola bilərlər. Səmərəlilik ölçülərini həll olunmamış işlər, təkrar müraciətlər və müştərilərin düzgün nəticə əldə etdiyinə dair sübutlarla tamamlayın.

FAQ

Kiçik mağazalara ayrıca izləmə, qaytarma və dəstək alətləri lazımdır?

Xeyr. Artıq mövcud olan imkanlardan və müəyyən edə bildiyiniz əməliyyat problemlərindən başlayın. Ayrı alətlər mövcud quruluş kifayət qədər görünürlük, siyasət nəzarəti və ya etibarlı ötürmələr təmin edə bilmədikdə faydalı olur. Aydın sahiblik olmadan daha çox tətbiq əl ilə işi artıra bilər.

İzləmə hadisələri avtomatik olaraq geri ödəniş başladmalıdır?

Yalnız uyğun yoxlamaları olan, açıq şəkildə təsdiqlənmiş iş axını çərçivəsində. Göndəriş hadisələri hərəkəti və ya çatdırılma fəaliyyətini təsvir edir; onlar mütləq geri ödənişə uyğunluğu müəyyən etmir. Tətik hadisəsini, icazə qərarını və maliyyə icrasını ayrı saxlayın.

İki alətin birlikdə işləməsi üçün API əlaqəsi kifayətdirmi?

Xeyr. Əlaqə həmçinin uyğun identifikatorlar, sahə xəritələndirməsi, icazələr, uğursuzluqların idarə edilməsi və ziddiyyətli yeniləmələr üçün qaydalar tələb edir. Hansı qeydlərin oxuna və dəyişdirilə biləcəyini təsdiqləyin və biznes iş axınını əvvəldən sona qədər sınaqdan keçirin.

Çatdırılmış kimi işarələnmiş qaytarma geri ödənilmiş kimi göstərilə bilər?

Təkcə bu sübuta əsasən yox. Qaytarma ünvanına çatdırılma, anbarın qəbulu, yoxlama, geri ödənişin təsdiqi və geri ödənişin uğurla icra edilməsi fərqli hadisələrdir. Müştəri mesajları faktiki təsdiqlənmiş mərhələni göstərməlidir.

Satışdan sonrakı stekin sahibi kim olmalıdır?

Elektron ticarət və ya əməliyyatlar rəhbəri ümumi sahib kimi praktik seçimdir; dəstək, logistika, maliyyə və texniki komandalar isə öz iş axınlarına cavabdeh olmalıdır. Problemlərin şöbələr arasında qalmasının qarşısını almaq üçün bir şəxs sistemlərarası uğursuzluqları koordinasiya etməlidir.

Mənbələr

Aşağıdakı rəsmi məhsul və sənədləşmə resursları yuxarıda müzakirə olunan 17TRACK qiymətləndirmə istiqamətləri üçün başlanğıc nöqtələridir. Tətbiqə xas tələbləri müvafiq sənədləşmə və məhsul şərtləri ilə yoxlayın.

• 17TRACK: göndəriş izləmə veb-saytı
• Shopify App Store: 17TRACK siyahısı
• 17TRACK: İzləmə API məlumatları
• 17TRACK: API sənədləri
• 17RETURNS: rəsmi məhsul səhifəsi