BaseLinker w sklepie internetowym

Scenariusz krok po kroku

1. 01

   Zamówienie jest widoczne, ale nadal się zmienia

   Wyobraźmy sobie sklep, który przekazuje nowe zamówienia do zewnętrznego obiegu obsługi. Zamówienie pojawia się na liście, lecz klient jeszcze uzupełnia sposób dostawy. Jeżeli integracja pobierze dokument zbyt wcześnie, pracownik może otrzymać niepełną listę produktów lub brakujące dane wysyłkowe. Późniejsze uzupełnienie nie powinno tworzyć drugiej, niezależnej sprawy dotyczącej tego samego zakupu.

   Dokumentacja pobierania zamówień w API Base zaleca pobieranie zamówień potwierdzonych. Wyjaśnia, że niepotwierdzone mogą być niekompletne i wkrótce się zmienić, ponieważ klient nadal kończy formularz. Moment przekazania danych trzeba dobrać do tego stanu.

   Potwierdzenie zamówienia w tym znaczeniu nie zastępuje sprawdzenia płatności ani przyjętych przez sklep warunków realizacji. W projektowanym obiegu uzgadniamy, jakie informacje są potrzebne do każdego kroku. Konsultant powinien widzieć, na co sprawa czeka, zamiast otrzymywać ogólny komunikat o błędzie.

2. 02

   Ten sam zakup musi zachować swoją historię

   Przy aktualizacji zamówienia potrzebne jest pewne powiązanie z wcześniejszym odczytem. W API występuje identyfikator zamówienia w Base oraz identyfikator pochodzący z zewnętrznego źródła. Dokumentacja opisuje również kanał i identyfikator źródła; ten ostatni jest unikalny dopiero w połączeniu z kanałem. Numer zamówienia skopiowany z wiadomości klienta wymaga więc ustalenia, którego źródła dotyczy.

   Proponowany widok może pokazywać pracownikowi takie sytuacje:

   Sytuacja	Co jest potrzebne do dalszej pracy
   Zamówienie jeszcze niepotwierdzone	Wskazanie, że dane mogą być niepełne
   Potwierdzony dokument z brakującym polem wymaganym przez sklep	Pytanie do osoby odpowiedzialnej za obsługę
   Ponowny odczyt tego samego zakupu	Aktualizacja istniejącej sprawy według ustalonych reguł
   Niejasny numer podany przez klienta	Sprawdzenie źródła przed przypisaniem wiadomości
   Przerwa w połączeniu	Informacja, od którego miejsca trzeba wznowić sprawdzenie

   Takie rozróżnienie pomaga zespołowi zrozumieć, dlaczego dokument nie trafił dalej. System nie powinien uzupełniać brakujących danych dostawy na podstawie podobnego zamówienia ani uznawać każdej kolejnej wiadomości za nowy zakup.

3. 03

   Najpierw reguły i historia w Base

   Dla stałych pól i jednoznacznych warunków często wystarczą reguły. Szerszą obsługę wyjątków, w tym zmianę adresu po przygotowaniu przesyłki, opisujemy na stronie BaseLinker i AI. Przed wyceną sprawdzamy obecne akcje, aby nowy obieg nie uruchamiał ponownie pracy już wykonanej w sklepie.

   Base udostępnia też dziennik zdarzeń zamówień. Dokumentacja określa jego zakres jako ostatnie trzy dni i zaznacza, że funkcja musi być włączona dla konta. Pusta odpowiedź nie wystarcza więc do uznania, że nic się nie wydarzyło. Przy dłuższej przerwie trzeba uzgodnić inny sposób odtworzenia brakującego zakresu.

   Projekt może obejmować przekazanie danych między Base a używanym narzędziem obsługi. Dostępność API nie potwierdza gotowej integracji Syntalith z konkretnym kontem sklepu. Odczyt, utworzenie sprawy i zmiana zamówienia mają osobne wymagania, które sprawdzamy przed budową.

4. 04

   Gdzie w tym obiegu przydaje się AI?

   Model może pomóc rozpoznać prośbę dopisaną swobodnym językiem, na przykład pytanie o połączenie przesyłek. Wynik trafia wtedy do przeglądu przy właściwym zamówieniu. Warunki płatności, kompletność wymaganych pól i rozpoznanie wcześniej przetworzonego dokumentu mogą być sprawdzane zwykłymi regułami.

   Jeżeli problemem jest przede wszystkim przygotowanie odpowiedzi, można zacząć od szkolenia zespołu na materiałach dopuszczonych przez sklep. Automatyzacja ma sens przy powtarzalnym zbieraniu danych. Własną aplikację lub agenta rozważamy, gdy konsultanci potrzebują wspólnego widoku wyjątków i historii decyzji. Pozostałe zastosowania pokazuje AI w e-commerce.

5. 05

   Co sprawdzimy przed uruchomieniem

   Próba powinna objąć zamówienie uzupełniane przez klienta, jego późniejsze potwierdzenie oraz ponowne pobranie tego samego dokumentu. Operator sprawdza, czy widzi jedną sprawę z właściwym stanem. Osobno trzeba przejść przez brak dostępu i wznowienie pracy, żeby ustalić, co zostało już przekazane do kolejnego systemu.

   Demonstracja przyjęcia zamówienia pokazuje kontrolę pozycji i zatrzymywanie niejasnych dopasowań na danych testowych. Nie łączy się z Base ani rzeczywistym ERP i nie potwierdza obsługi opisanych tu stanów zamówienia. Tę część trzeba sprawdzić na uzgodnionym środowisku i danych.

   Na pierwszej rozmowie opisz sytuację, w której niepełne zamówienie trafiło za wcześnie do obsługi lub pojawiło się ponownie. Ustalimy źródło danych i następny system w obiegu. Zakres wyceniamy z odniesieniem do cennika usług, oddzielnie ustalając połączenia i utrzymanie.