Ponowne wysyłanie potwierdzeń zamówień: mała funkcja, którą klienci naprawdę doceniają

Oto prośba, która regularnie wraca w każdej skrzynce pomocy technicznej sklepu PrestaShop: „Nie dostałem potwierdzenia zamówienia — czy możecie wysłać je ponownie?”. Brzmi banalnie i właśnie dlatego wiele sklepów obsługuje ją źle. Klient złożył zamówienie, e-mail został wysłany, a potem przepadł w folderze spamu, karcie Oferty albo został przypadkiem usunięty. Teraz klient nie ma numeru zamówienia, potwierdzenia płatności ani linku do śledzenia przesyłki — za to ma narastającą wątpliwość, czy zamówienie w ogóle zostało przyjęte. Rozwiązanie jest niewielkie, w dużej mierze oparte na tym, co PrestaShop już potrafi, i po cichu usuwa jedno z najbardziej powtarzalnych zadań Twojego zespołu. Ten poradnik dotyczy właśnie tej konkretnej funkcji: ponownego wysyłania e-maila z potwierdzeniem zamówienia — dziś z panelu administracyjnego, a jutro jako samoobsługi klienta.

Ostatnia aktualizacja: czerwiec 2026.

To jeden element większego procesu obsługi zamówień. Jeśli chcesz zobaczyć szerszy obraz sprawnego prowadzenia zamówień — statusy, działania masowe, codzienne rutyny — zacznij od tekstu o procesach obsługi zamówień, które oszczędzają godziny pracy. Tutaj skupiamy się wąsko: na tym, jak ponownie dostarczyć klientowi e-mail z potwierdzeniem.

Dlaczego e-maile z potwierdzeniem w ogóle giną

Właściciele sklepów często zakładają, że „e-mail wysłany” oznacza „e-mail przeczytany”. Tak nie jest. E-maile transakcyjne — potwierdzenie zamówienia, powiadomienie o wysyłce, faktura — walczą z tymi samymi filtrami antyspamowymi i automatycznym sortowaniem skrzynki co cała reszta poczty. Istotna część prawidłowych wiadomości transakcyjnych nigdy nie trafia do głównej skrzynki odbiorczej; dokładny odsetek bardzo zależy od konfiguracji wysyłki, więc nie warto przywiązywać się do jednej liczby. Masz natomiast wpływ na to, czy zagubiony e-mail zamieni się w zgłoszenie do obsługi, czy w jedno kliknięcie samoobsługowe.

Głębszą przyczyną w wielu sklepach PrestaShop jest infrastruktura wysyłkowa. Jeśli Twój sklep wysyła pocztę przez PHP mail() (Parametry zaawansowane → E-mail, domyślnie w wielu instalacjach), zamiast przez uwierzytelniony SMTP, potwierdzenia znacznie częściej trafiają do filtrów albo są po cichu odrzucane — brak zgodności SPF/DKIM, adres IP serwera bez reputacji wysyłkowej, nic, czemu serwer odbiorcy mógłby zaufać. Zanim zbudujesz jakąkolwiek funkcję ponownej wysyłki, warto naprawić przyczynę: przełączyć wysyłkę na SMTP, wysłać testowy e-mail z tego samego ekranu i potwierdzić, że SPF oraz DKIM są opublikowane dla Twojej domeny. Przycisk ponownej wysyłki nałożony na zepsutego nadawcę tylko ponownie wysyła pocztę, która także zostanie odfiltrowana.

Ponowne wysłanie potwierdzenia z panelu administracyjnego — co PrestaShop daje już dziś

Wielu sprzedawców to pomija, dlatego warto doprecyzować: PrestaShop potrafi ponownie wysłać e-mail związany ze statusem z poziomu strony zamówienia, bez dodatkowego modułu — ale z ważnym zastrzeżeniem. Otwórz Zamówienia → Zamówienia, wejdź w konkretne zamówienie i spójrz na panel Status u góry. Lista rozwijana robi więcej niż tylko opisuje zamówienie — ponowne zastosowanie albo zmiana statusu na taki, który ma przypisany szablon e-maila, uruchamia ten szablon ponownie. Nie pozwala to jednak w czysty sposób wysłać ponownie pierwotnego potwierdzenia zamówienia: to potwierdzenie jest generowane podczas walidacji zamówienia, a nie przez zwykły e-mail statusu zamówienia, więc w standardowej instalacji nie ma natywnego przycisku „wyślij ponownie potwierdzenie”, który odtworzy je bez zmiany statusu zamówienia i bez skutków ubocznych. Do czystej, pozbawionej skutków ubocznych ponownej wysyłki pierwotnego potwierdzenia potrzebna jest logika własna albo moduł.

Mechanizm opiera się na konfiguracji statusów zamówień. Każdy status (możesz je sprawdzić w Parametry sklepu → Ustawienia zamówień → Statusy, zapisane w tabeli ps_order_state) ma flagę „Wyślij e-mail do klienta, gdy zamówienie ma ten status” oraz powiązany szablon. Statusy „Oczekiwanie na płatność” / „Płatność zaakceptowana” / „Przygotowanie w toku” wskazują na szablony takie jak payment albo preparation. Pierwotne potwierdzenie zamówienia (order_conf) działa inaczej — jest wysyłane podczas procesu walidacji zamówienia/płatności, a nie jako rutynowy e-mail statusu zamówienia, który można ponownie uruchomić z listy rozwijanej. Praktycznie więc dla e-maila statusowego robisz tak: ustawiasz zamówienie z powrotem na status, którego wiadomość klient powinien był otrzymać, a PrestaShop wysyła ten e-mail statusowy ponownie. Pod spodem odbywa się to przez OrderState oraz wpis w historii zamówienia (OrderHistory::addWithemail()), czyli tę samą ścieżkę, którą przeszła pierwotna automatyczna wiadomość — klient otrzymuje więc identyczny, poprawnie sformatowany komunikat, a nie ręcznie sklejoną imitację.

Jest tu jednak ostra krawędź i właśnie dlatego istnieje dedykowane narzędzie. Zmiana statusu zamówienia w celu ponownego wywołania e-maila również dopisuje nową pozycję do historii zamówienia i może przesunąć zamówienie w procesie obsługi. W zależności od statusu może też uruchomić zachowania związane z fakturą lub dokumentem dostawy, wywołać hooki i odpalić automatyzacje modułów przypięte do tego statusu (a ruchy magazynowe wchodzą w grę tylko przy statusach anulowania, zwrotu lub ponownego przyjęcia na stan). Jeśli chodziło Ci wyłącznie o ponowne wysłanie e-maila, właśnie zabrudziłeś oś czasu zamówienia, być może uruchomiłeś skutki uboczne powiązane z tym statusem i utrudniłeś późniejsze czytanie historii. Przy pojedynczym przypadku da się z tym żyć. Jako codzienny nawyk przy dziesiątkach zamówień — robi się bałagan.

Czystsza droga w panelu administracyjnym: prawdziwe „wyślij ponownie” bez dotykania statusu

Zespoły obsługi naprawdę potrzebują przycisku, który ponownie wysyła potwierdzenie bez zmieniania czegokolwiek w zamówieniu — ten sam szablon, te same dane, brak nowej linii statusu, brak skutków ubocznych. Właśnie tę lukę wypełnia nasz moduł Resend Order Confirmation: dodaje do strony szczegółów zamówienia w panelu administracyjnym jedno kliknięcie do ponownej wysyłki. Co to oznacza w praktyce? Gdy klient pisze do obsługi, pracownik otwiera zamówienie, klika raz, a pierwotne potwierdzenie wychodzi ponownie — bez szukania właściwego szablonu, bez ręcznego pisania e-maila, bez zmiany statusu zanieczyszczającej historię zamówienia. Pracownik poświęca piętnaście sekund zamiast pięciu minut, a rekord zamówienia pozostaje czysty.

To mała funkcja, ale rachunek czasu jest bardzo realny. Ręczna obsługa ponownej wysyłki — znalezienie zamówienia, weryfikacja tożsamości, odszukanie szablonu, ponowna wysyłka albo cofanie statusu — łatwo pochłania od pięciu do dziesięciu minut wykwalifikowanej pracy wsparcia na jedno zgłoszenie, zwłaszcza gdy doliczyć przełączanie kontekstu i dodatkowe sprawdzenia. Sklep, który dostaje choć kilka takich próśb tygodniowo, traci miesięcznie godziny na zadanie niewymagające żadnej oceny eksperckiej. Ten czas lepiej przeznaczyć na sprawy, które naprawdę potrzebują człowieka: uszkodzoną dostawę, spór o zwrot pieniędzy, zmianę adresu po wysyłce.

Ponowna wysyłka przez status czy dedykowany przycisk — czego użyć

Lepsze niż ponowne wysyłanie: spraw, aby klient nie musiał pytać

Najszybsze zgłoszenie do pomocy to takie, które nigdy nie powstało. PrestaShop już udostępnia klientowi dużo danych o zamówieniu na jego koncie — gdy zalogowany klient przechodzi do Historii zamówień (kontroler history) i klika Szczegóły (kontroler order-detail, obsługiwany przez order-detail.tpl), widzi pełne zamówienie, pozycje, oś statusów i ewentualną fakturę. W większości próśb typu „gdzie jest moje potwierdzenie?” odpowiedź już znajduje się na tej stronie — klient po prostu nie wiedział, że powinien tam zajrzeć.

Dwa kroki domykają temat:

• Niech strona szczegółów zamówienia wystarcza sama w sobie. Jeśli pełna treść potwierdzenia — numer zamówienia, produkty, sumy, adres dostawy, metoda płatności — jest widoczna na koncie, e-mail staje się wygodnym dodatkiem, a nie jedynym dowodem. Klient, który widzi swoje zamówienie online, rzadko potrzebuje ponownej wysyłki wiadomości.
• Dodaj link „wyślij ponownie potwierdzenie” na koncie klienta. Pojedynczy link na stronie szczegółów zamówienia, który ponownie wysyła potwierdzenie na adres e-mail konta, zamienia zgłoszenie do pomocy w samoobsługowe kliknięcie. Sprawa nigdy nie trafia do skrzynki obsługi. To ten sam mechanizm ponownej wysyłki co przycisk w panelu administracyjnym, po prostu udostępniony zalogowanemu klientowi dla jego własnych zamówień.

Jedno zastrzeżenie warto powiedzieć wprost: samoobsługa pomaga tylko klientom, którzy korzystali z konta. Gość, który złożył zamówienie bez rejestracji — i pomylił się w adresie e-mail — nie może zalogować się, żeby cokolwiek znaleźć, a to dokładnie ten przypadek, w którym konfiguracja SMTP i ponowna wysyłka z panelu administracyjnego są najważniejsze. Dlatego potrzebujesz obu rozwiązań: samoobsługi dla posiadaczy kont i czystej ponownej wysyłki z panelu dla wszystkich pozostałych.

Ta sama logika dotyczy każdego e-maila transakcyjnego

Gdy potraktujesz „klient zgubił e-mail” jako powtarzalny problem do rozwiązania, a nie pojedynczą ręczną czynność za każdym razem, ten sam wzorzec obejmuje całą komunikację zamówieniową:

• Faktury. Faktura to e-mail, o którego ponowną wysyłkę klienci proszą najczęściej — do księgowości, rozliczenia kosztów, reklamacji lub zwrotu. PrestaShop dołącza fakturę PDF do zamówienia od momentu, gdy ma ono poprawny numer faktury; upewnij się, że klienci mogą pobrać ją z konta, a jeśli regularnie eksportujesz faktury do księgowości, zobacz eksporty CSV dla zamówień i faktur.
• Powiadomienia o wysyłce. „Gdzie jest mój link do śledzenia?” to ten sam problem w innym ubraniu — klient zgubił e-mail statusowy (szablon shipped). Logika ponownej wysyłki jest identyczna.
• Potwierdzenia po edycji zamówienia. Jeśli po złożeniu zamówienia zmieniłeś pozycje, cenę albo adres, pierwotne potwierdzenie jest już nieaktualne — ponowne wysyłanie starego jest gorsze niż bezużyteczne. Wyślij poprawione potwierdzenie dopiero wtedy, gdy edycja jest ostateczna; mechanikę edytowania istniejącego zamówienia omawiamy w tekście edycja zamówienia: poprawianie błędów po złożeniu zamówienia przez klienta.

Nie zawyżaj statystyk — najpierw posprzątaj zamówienia testowe

Jedna uwaga operacyjna, która potrafi ugryźć sklepy budujące lub testujące funkcje e-mailowe: podczas dopracowywania szablonów łatwo zasypać siebie ponownymi wysyłkami i równie łatwo zostawić za sobą stertę fikcyjnych zamówień. Jeśli testowałeś na sklepie produkcyjnym albo prawie produkcyjnym, usuń dane testowe, zanim zniekształcą liczniki zamówień i wywołają przypadkowe e-maile — zobacz usuwanie zamówień testowych przed uruchomieniem sklepu.

Najczęściej zadawane pytania

Dlaczego w standardowym PrestaShop nie mogę po prostu ponownie wysłać pierwotnego potwierdzenia zamówienia ze strony zamówienia? Ponieważ potwierdzenie (szablon order_conf) jest generowane raz podczas walidacji zamówienia, a nie jako rutynowy e-mail statusu zamówienia. Lista Status ponownie uruchamia tylko e-maile przypisane do stanu zamówienia — więc jedyną natywną metodą „ponownej wysyłki” jest zmiana statusu, która zapisuje nową pozycję w historii i może uruchomić skutki uboczne. Czysta, pozbawiona skutków ubocznych ponowna wysyłka pierwotnego potwierdzenia wymaga logiki własnej albo modułu.

Czy ponowne wysłanie e-maila obciąży klienta drugi raz albo zmieni zamówienie? Nie. Wysłanie e-maila nigdy nie dotyka płatności, stanów magazynowych ani sum — jedynie dostarcza wiadomość ponownie. Ryzyko, którego obawiają się użytkownicy, wynika z obejścia polegającego na zmianie statusu w celu wywołania e-maila, a nie z samego e-maila. Dedykowana ponowna wysyłka, która nie zmienia statusu, zostawia zamówienie całkowicie nietknięte.

Moje potwierdzenia nadal trafiają do spamu nawet po ponownej wysyłce. Co teraz? Ponowna wysyłka nie naprawi problemu z nadawcą — druga kopia zostanie odfiltrowana tak samo jak pierwsza. Sprawdź Parametry zaawansowane → E-mail: jeśli używasz PHP mail(), przełącz się na uwierzytelniony SMTP, wyślij testowy e-mail z tego ekranu i potwierdź, że SPF oraz DKIM są opublikowane dla Twojej domeny. Najpierw napraw nadawcę, potem wysyłaj ponownie.

Gość złożył zamówienie i pomylił się w adresie e-mail — czy może otrzymać potwierdzenie? Nie przez samoobsługę, bo nie ma konta, na które mógłby się zalogować. To dokładnie przypadek, w którym liczy się ponowna wysyłka z panelu administracyjnego: popraw adres e-mail w zamówieniu, jeśli Twoja wersja na to pozwala, a potem wyślij potwierdzenie ponownie na poprawiony adres.

Czy moduł działa w mojej wersji PrestaShop? Kontrolka ponownej wysyłki jest podpięta do strony szczegółów zamówienia i tej samej ścieżki e-mailowej, której PrestaShop już używa, więc działa w obsługiwanych przez nas gałęziach 1.6, 1.7, 8 i 9 — bazowy mechanizm OrderHistory/mail pozostał zgodny.

Wniosek

„Wyślijcie ponownie moje potwierdzenie” to drobna prośba, która pokazuje, jak sklep traktuje klientów. Obsłuż ją źle, a staje się pięciominutową ręczną czynnością i jednocześnie sygnałem dla klienta, że nie byliście przygotowani na oczywisty problem. Obsłuż ją dobrze, a staje się niewidoczna: nadawca jest skonfigurowany tak, żeby mniej e-maili ginęło, ponowna wysyłka z panelu administracyjnego to jedno czyste kliknięcie, które nie miesza w historii zamówienia, a klient zwykle może sam otworzyć zamówienie i wysłać potwierdzenie ponownie bez kontaktu z obsługą. Nie ma w tym rewolucyjnej inżynierii — to ten rodzaj cichego, dopracowanego szczegółu, który sprawia, że sklep wydaje się niezawodny i który klienci pamiętają przy następnym wyborze miejsca zakupu.