Automatyzacja SMS w PrestaShop i WooCommerce. Co sprawdzić przed startem
1. Zdarzenie i rzeczywisty stan zamówienia
Automatyzacja potrzebuje konkretnego sygnału ze sklepu. Sam status „wysłane” nie zawsze oznacza, że paczka została przekazana kurierowi: w danym sklepie może opisywać zakończenie pakowania albo zmianę wykonaną przez system magazynowy. Podobnie potwierdzenie płatności może dotrzeć po czasie. Najpierw ustal, co dany status oznacza w Twoim procesie, a dopiero potem powiąż go z SMS-em.
Dla każdej wiadomości zapisz: zdarzenie, warunek wysyłki, odbiorcę, potrzebne dane i wyjątki. Przykład: „wyślij informację o nadaniu dopiero po otrzymaniu numeru przesyłki; pomiń zamówienia anulowane”. Sprawdź też statusy dodane przez moduły lub własne integracje. Gotowa konfiguracja może ich nie uwzględniać.
Przykład z płatnością pokazuje, dlaczego ta mapa jest potrzebna. Zamówienie z przelewem tradycyjnym może istnieć, choć sklep jeszcze nie otrzymał pieniędzy. Komunikat „dziękujemy za płatność” powinien mieć inny wyzwalacz niż „otrzymaliśmy zamówienie”. W przypadku płatności online sprawdź, co się dzieje po opóźnionym potwierdzeniu od operatora i przy ponownej próbie płatności. Nie zakładaj, że moment utworzenia zamówienia rozstrzyga oba przypadki.
Dobrze działający scenariusz rozdziela też zdarzenie od decyzji o wysyłce. Pojawienie się nowego statusu nie musi jeszcze oznaczać, że klient powinien dostać wiadomość. Reguła może dodatkowo sprawdzić metodę płatności, numer przesyłki lub wcześniejszą wysyłkę. Dzięki temu jeden komunikat nie zależy od przypadkowego kliknięcia w panelu.
W WooCommerce przyjrzyj się zmianom statusu i potwierdzeniu płatności przez używaną bramkę. W PrestaShop sprawdź, czy moduł reaguje przed zapisaniem zmiany statusu czy po niej. Ta różnica może decydować o tym, jakie dane integracja odczyta. Przy niestandardowym checkoutcie lub systemie ERP testuj faktyczny przebieg zamówienia, nie tylko nazwy zdarzeń z dokumentacji.
2. Dane klienta i porzucony koszyk
Numer telefonu trzeba ujednolicić i sprawdzić, zanim trafi do wysyłki. Walidacja formatu wykryje oczywiste błędy, lecz nie potwierdzi, że numer należy do kupującego. W sklepie wielojęzycznym powiąż z zamówieniem także kraj i język komunikatu. Przy zakupie bez konta korzystaj z danych konkretnego zamówienia, a nie zakładaj, że istnieje aktualny profil klienta.
Jeśli ten sam telefon widnieje przy kilku kontach lub zamówieniach, nie zakładaj od razu, że dane są błędne. Klienci mogą zamawiać dla bliskich albo korzystać ze wspólnego numeru. Dla wiadomości o konkretnym zamówieniu kluczowe jest ustalenie, który numer podano do tego zamówienia i kto powinien otrzymać dany rodzaj powiadomienia.
Porzucony koszyk wymaga osobnej oceny. Samo dodanie produktu do koszyka zwykle nie daje sklepowi numeru telefonu. Nawet gdy kupujący wpisze go w checkoutcie, dane nie muszą być jeszcze dostępne dla automatyzacji. Ustal więc, na jakim etapie integracja rzeczywiście je otrzymuje.
Przed wdrożeniem poproś o odpowiedź na trzy pytania: czy sklep zapisał już telefon, z jakim koszykiem można go połączyć oraz jak rozpozna późniejszy zakup tego samego klienta. Jeśli system nie potrafi tego wiarygodnie ustalić, lepiej odłożyć SMS o porzuconym koszyku i zacząć od powiadomień o zamówieniu. To decyzja o jakości danych, a nie ograniczenie samego kanału SMS.
W WooCommerce z blokowym checkoutem może powstać zamówienie robocze, ale sam jego status nie oznacza opłaconego zakupu. W PrestaShop dostępność telefonu również zależy od sposobu realizacji koszyka i zastosowanych modułów. Dlatego odzyskiwania koszyka nie warto traktować jako ustawienia, które działa identycznie we wszystkich sklepach.
Tuż przed wysyłką przypomnienia sprawdź ponownie, czy zakup nie został sfinalizowany, czy odbiorca nie dostał już podobnej wiadomości i czy spełnione są warunki kontaktu marketingowego. Taka kontrola jest ważniejsza niż samo ustawienie opóźnienia po opuszczeniu checkoutu.
3. Moduł, webhook czy API
Gotowy moduł to sensowny punkt startowy przy prostych powiadomieniach opartych na statusach. SerwerSMS udostępnia integracje z PrestaShop i WooCommerce; przed instalacją sprawdź aktualną zgodność modułu z wersją sklepu i to, które zdarzenia rzeczywiście obsługuje.
Webhook lub integracja przez API daje więcej swobody, gdy wysyłka zależy także od ERP, magazynu, kuriera albo własnych reguł. WooCommerce udostępnia webhooki i REST API, a SerwerSMS ma HTTPS API. Wybór powinien wynikać ze scenariusza, liczby systemów i możliwości utrzymania rozwiązania. Nie każdy sklep potrzebuje własnego połączenia od zera.
Przy gotowym module zapytaj, czy potrafi obsłużyć własne statusy, różne języki i warunki wykluczające. Przy połączeniu przez API ustal, kto odpowiada za mapowanie zdarzeń, aktualizacje i diagnozowanie błędów. Ważna jest również zgodność z aktualną wersją platformy po kolejnych aktualizacjach sklepu. Te pytania zwykle więcej mówią o jakości wdrożenia niż sama liczba opcji w panelu.
Niezależnie od metody przetestuj, czy numer, język, treść i właściwy moment wysyłki zgadzają się z danymi zamówienia. Sam fakt, że moduł się zainstalował, nie potwierdza poprawności całego procesu.
4. Integracja dopasowana do procesów sklepu
Sposób połączenia sklepu z SerwerSMS zależy od tego, jakie wiadomości chcesz wysyłać i skąd pochodzą potrzebne dane. Przy powiadomieniach opartych na zdarzeniach w sklepie warto zacząć od sprawdzenia możliwości gotowego modułu. Jeśli o wysyłce decydują także dane z ERP, magazynu lub systemu kurierskiego, rozwiązanie trzeba dopasować do całego procesu.
Niezależnie od wybranej metody określ,co uruchamia SMS, kiedy nie należy go wysyłać i jak zespół sprawdzi historię komunikacji. Przetestuj również sytuację, w której kilka systemów aktualizuje to samo zamówienie, aby klient nie otrzymał powtórnej wiadomości.
Zadbaj o bezpieczne przechowywanie danych dostępowych po stronie serwera i przyznaj integracji tylko potrzebne uprawnienia. Dzięki temu komunikacja będzie odpowiadać sposobowi działania Twojego sklepu.
5. Komunikaty transakcyjne i marketingowe
Przy tworzeniu scenariuszy ustal także, czy komunikat jest rzeczywiście potrzebny klientowi. Nie każda zmiana wewnętrznego statusu wymaga SMS-a. Jeśli sklep wysyła już e-mail o tej samej treści, kolejny kanał warto uruchamiać świadomie, z uwzględnieniem kosztu, pilności informacji i preferencji odbiorcy.
Informacja potrzebna do obsługi złożonego zamówienia i SMS zachęcający do kolejnego zakupu pełnią różne funkcje. Nie przenoś automatycznie podstawy kontaktu dotyczącego zamówienia na wiadomości sprzedażowe. Rabat, oferta lub przypomnienie o niedokończonym zakupie mogą stanowić informację handlową lub marketing bezpośredni. O kwalifikacji decydują cel i treść konkretnej wiadomości.
W Polsce art. 398 Prawa komunikacji elektronicznej reguluje uprzednią zgodę na używanie kanału do przesyłania informacji handlowej, w tym marketingu bezpośredniego. Osobno trzeba ustalić podstawę przetwarzania danych na gruncie RODO. W sklepie zapisuj zakres, kanał, datę i źródło zgody oraz jej wycofanie; jeśli korzystasz z kilku narzędzi, zapewnij spójny status kontaktu we wszystkich.
Zgoda na kontakt marketingowy nie jest tym samym co podanie telefonu przy zakupie. Trzeba móc wykazać, na co odbiorca się zgodził, a po wycofaniu zgody powstrzymać wysyłkę także wtedy, gdy scenariusz był już zaplanowany. Warto sprawdzić to w teście obejmującym sklep, narzędzie marketing automation i system SMS. W odniesieniu do powiadomień o zamówieniu unikaj dokładania do treści promocji, jeśli komunikat miał służyć wyłącznie obsłudze zakupu.
Przy porzuconym koszyku, wiadomościach łączących status zamówienia z promocją albo sprzedaży do innych krajów uzgodnij zasady z prawnikiem lub IOD. Taki przegląd najlepiej zrobić przed zbudowaniem scenariusza, nie dopiero przed pierwszą wysyłką.
6. Testy przed uruchomieniem
Przejdź z developerem przynajmniej te scenariusze:
- złożone i opłacone zamówienie oraz płatność opóźniona lub nieudana;
- zmiana statusu, ponowne przetworzenie zdarzenia, anulowanie i zwrot;
- brak numeru, błędny numer, zamówienie gościa oraz inny kraj lub język;
- wycofana zgoda i zakup dokończony tuż przed przypomnieniem o koszyku;
- chwilowa niedostępność systemu SMS i ponowienie po błędzie.
Spisz oczekiwany wynik każdego testu przed jego wykonaniem. Przy powtórnym wywołaniu zdarzenia oczekujesz jednego SMS-a; przy braku numeru – żadnego; przy anulowaniu przed zaplanowaną wysyłką – zatrzymania komunikatu. Sam zielony status w narzędziu wysyłkowym nie wystarcza, jeśli odbiorca, treść lub moment były niewłaściwe.
Test wykonaj na ścieżce, z której korzystają klienci: z rzeczywistą bramką płatniczą w trybie testowym, używanym modułem wysyłkowym i checkoutem na telefonie. Sprawdź godzinę wysłania, dane w treści oraz to, co widzi obsługa w logu, gdy wiadomość nie dochodzi. Jeśli reguły zależą od zewnętrznego ERP lub kuriera, zasymuluj także opóźnienie aktualizacji danych.
Po starcie kontroluj nie tylko liczbę wysłanych wiadomości, ale również błędy, duplikaty, statusy doręczenia i wypisy z komunikacji. Status doręczenia nie mówi jeszcze, czy klient przeczytał SMS ani czy wiadomość przyniosła efekt biznesowy.
Co zrobić teraz
Dobrym materiałem do przekazania developerowi jest mała tabela z kolumnami: komunikat, źródło zdarzenia, warunek, numer i język, wykluczenia oraz wynik testu. Jedna taka tabela ułatwia ustalenia między marketingiem, obsługą klienta i technologią. Pozwala też wychwycić scenariusze, w których źródłem prawdy jest system płatności lub magazyn, a nie panel sklepu.
Zacznij od jednego scenariusza, na przykład informacji o nadaniu przesyłki. Zmapuj zdarzenie, dane i wyjątki, a następnie przetestuj cały proces na zamówieniach próbnych. To prostszy sposób na ocenę gotowości sklepu niż uruchamianie wielu wiadomości jednocześnie.
Jeśli chcesz sprawdzić techniczną stronę PrestaShop lub WooCommerce i przygotować integrację, porozmawiaj z zespołem Woohoo.