Co miesiąc, około dziesiątego, zespół księgowy wysyła tę samą prośbę. Potrzebują pięciu plików od każdego klienta: wyciągu bankowego, archiwum paragonów, raportu płacowego, podsumowania sprzedaży i dokumentu inwentaryzacyjnego. Szablon jest przyjazny, precyzyjny i przetestowany. Wita klienta po imieniu, wymienia pliki i podaje jasny termin. Przy pierwszej wysyłce wszystko działa. Klient widzi uporządkowaną listę i odpowiada.

Problemy zaczynają się przy drugim e-mailu.

Wyobraźmy sobie, że jeden klient przesyła cztery pliki. Piąty wyciąg bankowy nigdy nie dociera. Archiwum paragonów pojawia się, ale dotyczy niewłaściwego miesiąca, więc zespół je odrzuca. Raport płacowy dotarł już trzy dni temu przez Slacka i ktoś go już zarejestrował. Dokument inwentaryzacyjny w ogóle nie dotyczy tego klienta – szczegół, który odkryłeś dopiero po wysłaniu pierwszej wiadomości. Jeśli wyślesz ponownie oryginalny szablon, ponownie poprosisz o pięć plików. Cztery z tych próśb są teraz bezcelowe. Jedna jest wręcz myląca. Treść jest w porządku. Problem polega na tym, że e-mail po prostu nie ma pamięci.

Szablon e-maila dobrze radzi sobie z imionami, datami i instrukcjami. W przypadku małej, jednorazowej prośby zazwyczaj to wystarcza. Jedna osoba wysyła wiadomość, klient odpowiada, a ta sama osoba kończy zadanie. Historia żyje w jednym umyśle i jednej skrzynce odbiorczej.

Problemy zaczynają się, gdy kolejna wiadomość zależy od zdarzeń, które miały miejsce po wysłaniu pierwszego e-maila. Szablon nadal pokazuje pierwotną listę. Nie wie, że wyciąg bankowy dotarł wczoraj. Nie wie, że raport płacowy został odrzucony. Te dane znajdują się w skrzynce odbiorczej, być może kilku skrzynkach, a aplikacja generująca przypomnienie nie ma sposobu, aby je odczytać.

Gdy status „otwarty” to za mało

Jeśli śledzisz całą prośbę jako pojedynczy status, np. „otwarty”, tracisz istotne szczegóły. Poszczególne elementy poruszają się niezależnie. Każdy z nich potrzebuje własnego stanu, aby kolejna komunikacja mogła być dokładna:

  • Wyciąg bankowy: Brak. Klient go nie przesłał.
  • Archiwum paragonów: Przesłane, ale nieprzejrzane. Czeka w folderze na wewnętrzną weryfikację.
  • Raport płacowy: Odrzucony. Klient coś przesłał, ale był to niewłaściwy format lub niewłaściwy okres rozliczeniowy.
  • Raport sprzedaży: Otrzymany innym kanałem. Dotarł przez Slacka, telefonicznie lub w formie papierowej, a Twój zespół już go zarejestrował.
  • Dokument inwentaryzacyjny: Nie dotyczy. Ten klient nie musi go dostarczać i system powinien przestać o niego prosić.

Bez takiego podziału Twoje przypomnienie jest „ślepe”. Traktuje brakujący plik i odrzucony plik w ten sam sposób. Traktuje plik, który jest już w Twoich rękach, tak jakby nigdy nie dotarł. To marnuje czas klienta i podkopuje zaufanie. Po dwóch lub trzech nieistotnych przypomnieniach klienci przestają czytać uważnie. Zakładają, że Twój system nie działa.

Buduj tylko to, czego potrzebujesz

Nie buduj od razu potężnego silnika reguł. Pierwszego dnia nie potrzebujesz automatyzacji workflow z dwudziestoma gałęziami warunkowymi. Zacznij od śledzenia tylko wystarczającej ilości danych, aby odpowiedzieć na jedno pytanie: Co nadal wymaga działania ze strony klienta?

Każdy wnioskowany element wymaga trwałego zapisu. Oznacza to rekord, który istnieje poza wątkiem e-mailowym, w miejscu, które aplikacja może odczytać podczas tworzenia kolejnej wiadomości. Ten rekord nie musi być skomplikowany. Może być tak prosty, jak ustrukturyzowana tabela zawierająca nazwę elementu, jego aktualny stan, znacznik czasu i krótką notatkę. Ważne jest to, aby dane przetrwały poza skrzynką odbiorczą.

To zmienia rolę e-maila. Szablon nadal kontroluje ton i strukturę. Powitanie pozostaje serdeczne, a instrukcje jasne. Jednak lista dokumentów musi pochodzić z danych prośby. Przypomnienie staje się zapytaniem. Filtrujesz listę, aby pokazać tylko te elementy, które wymagają działania klienta. Wykluczasz elementy czekające na wewnętrzną weryfikację. Wykluczasz elementy, które zostały już zaakceptowane.

Jeśli przesłany plik został odrzucony, przypomnienie powinno o tym wspomnieć i wyjaśnić dlaczego. Nie powinno po cichu umieszczać dokumentu na ogólnej liście, jak gdyby klient po prostu zapomniał go wysłać. Klient wie, że coś przesłał; udawanie, że nie, sprawia, że wyglądasz na niezorganizowanego.

Test przekazania

Istnieje prosty sposób, aby dowiedzieć się, czy potrzebujesz tego dodatkowego modelu danych. Zapytaj:

Czy inny członek zespołu mógłby przejąć tę prośbę bez czytania całego wątku e-mailowego?

W przypadku pojedynczego pliku odpowiedź nie ma znaczenia. W przypadku powtarzających się miesięcznych zapytań z wieloma zależnościami, ma ona ogromne znaczenie. Jeśli główny kontakt jest na urlopie, czy współpracownik w kilka sekund sprawdzi, czego brakuje? Czy menedżer jest w stanie stwierdzić, czy klient jest na bieżąco, bez otwierania dziesięciu e-maili i trzech współdzielonych folderów? Jeśli jedynym miejscem, w którym odnotowano odrzucenie, jest czwarta wiadomość w wątku, ukryta pod podpisami i przekazanymi wiadomościami, to Twój system zmusza ludzi do wykonywania pracy, którą powinna wykonać baza danych.

Szablony ulepszają treść wiadomości. Śledzone zapytanie zachowuje historię. Jeden element odpowiada za to, jak się komunikujesz. Drugi za to, co wiesz.

Zapytania, a nie skrypty

Gdy masz już stany na poziomie poszczególnych elementów, generowanie e-maila zmienia się ze skryptowania w zapytania. Wcześniej pisałeś akapit i miałeś nadzieję, że informacje wciąż są aktualne. Teraz pytasz swoje dane: które z tych elementów wymagają jeszcze działania klienta? Tworzysz przypomnienie w oparciu o tę przefiltrowaną listę. Jeśli nic nie wymaga działania, nie wysyłasz przypomnienia w ogóle. Jeśli dwa elementy wymagają działania, a jeden został odrzucony z konkretnego powodu, e-mail buduje się wokół tych faktów.

To