Potrzebujesz
Działającego
Designu?
wykonamy.net


Autor: Ernest Moskała · Opublikowano:
Automatyczne tworzenie i wysyłanie ofert polega na połączeniu danych klienta z CRM, szablonem dokumentu oraz pocztą. Po spełnieniu ustalonego warunku system pobiera dane, składa ofertę, przekazuje ją do akceptacji i wysyła. Proces powinien także zapisać dokument, status wysyłki oraz termin dalszego kontaktu.
Automatyczne tworzenie i wysyłanie ofert wymaga połączenia CRM, uporządkowanych danych, szablonu dokumentu i kanału komunikacji. Po określonym zdarzeniu system uzupełnia ofertę, przekazuje ją do kontroli lub wysyła klientowi. Następnie zapisuje dokument, wiadomość i status sprawy.
Proces zaczyna się od zdarzenia, które system może jednoznacznie rozpoznać. Może to być zmiana etapu szansy sprzedażowej, zatwierdzenie wyceny lub uzupełnienie formularza przez handlowca.
System pobiera dane klienta i zakres zamówienia z ustalonego źródła, po czym wstawia je do szablonu. Tak powstaje dokument z nazwą firmy, zakresem, warunkami i danymi osoby prowadzącej sprawę.
Gotowa oferta może trafić do akceptacji. Jeśli nie jest ona wymagana, system przygotowuje wiadomość, dołącza dokument i wysyła go na zapisany adres. Na końcu aktualizuje CRM i tworzy zadanie dotyczące dalszego kontaktu.
Czynności te powinny tworzyć jeden kontrolowany workflow. Rekord w CRM przekazuje wartości do szablonu. Dokument może zostać zapisany w Microsoft SharePoint, przekształcony do PDF i dołączony do wiadomości. Handlowiec nie musi wtedy kopiować tych samych informacji między systemami, a każda oferta powstaje według ustalonej kolejności.
Dokument można generować z szablonu i danych za pomocą przepływu uruchamianego po utworzeniu lub zmianie rekordu. Takie rozwiązanie opisuje dokumentacja Microsoft dotycząca automatyzacji dokumentów (źródło: https://learn.microsoft.com/pl-pl/microsoft-365/documentprocessing/automate-document-generation?view=o365-worldwide).
Najpierw określ, kiedy oferta ma powstać. Warunek „gdy klient jest zainteresowany” jest dla systemu zbyt niejasny. Potrzebne jest konkretne zdarzenie zapisane w danych.
Wyzwalaczem może być ustawienie statusu „oferta gotowa” albo zatwierdzenie zakresu przez odpowiedzialną osobę. Trzeba też wskazać warunki wykluczające. Proces nie powinien ruszyć, jeśli brakuje adresu e-mail, ceny lub danych nabywcy.
Proces trzeba zabezpieczyć przed duplikatami. Ponowna edycja rekordu nie może za każdym razem powodować wysłania tego samego dokumentu. Można temu zapobiec za pomocą osobnego statusu wysyłki albo identyfikatora wygenerowanej oferty.
Status przygotowania dobrze jest oddzielić od statusu wysyłki. Rekord może kolejno przyjmować wartości „dane kompletne”, „oczekuje na akceptację”, „zaakceptowana”, „wysłana” i „błąd wysyłki”. Pozwala to ustalić, gdzie zatrzymała się sprawa, oraz wznowić proces bez powtarzania wcześniejszych operacji.
Automatyzacja działa na danych, nie na domysłach. CRM lub formularz powinien zawierać wszystkie informacje wymagane przez szablon. Nazwy i formaty pól muszą być spójne.
Dane klienta należy oddzielić od danych handlowych. Pierwsza grupa obejmuje między innymi nazwę firmy, adres i dane kontaktowe. Druga opisuje zakres, wariant, warunki płatności, termin realizacji i osobę odpowiedzialną.
Przed wygenerowaniem dokumentu system powinien sprawdzić pola obowiązkowe. Jeśli czegoś brakuje, może zatrzymać proces i utworzyć zadanie uzupełnienia danych. Zapobiega to wysłaniu niepełnej oferty.
Kontrola powinna obejmować obecność wartości i ich format. Kwota musi być liczbą wyświetlaną w ustalonej walucie, termin powinien mieć jednoznaczny zapis, a adres e-mail poprawną strukturę. Jeśli dane klienta pochodzą z innego systemu, trzeba wskazać źródło nadrzędne. Dokument nie będzie wtedy zawierał innego adresu lub nazwy niż rekord używany przez handlowca.
Szablon powinien zawierać stałe fragmenty i oznaczone miejsca na dane zmienne. Stałe elementy to na przykład informacje o firmie, opis procesu i warunki formalne. Dane klienta i szczegóły propozycji są zmienne.
Trzeba też przewidzieć sekcje opcjonalne. Jeśli wybrana usługa nie obejmuje danego elementu, związany z nim akapit powinien zniknąć, zamiast pozostać pusty. Ta sama zasada dotyczy tabel, rabatów i załączników.
Sprawdź wygląd krótkich i długich wartości. Nazwa firmy lub rozbudowany zakres mogą zmienić układ stron. Test powinien objąć polskie znaki, podziały wierszy i sposób prezentacji kwot.
Nazwy pól w szablonie powinny odpowiadać polom przekazywanym przez workflow. Trzeba też ustalić sposób nazywania plików, na przykład przez połączenie numeru oferty, nazwy klienta i numeru wersji. Po wygenerowaniu otwórz plik i sprawdź, czy nie zostały w nim znaczniki bez wartości, puste wiersze lub tabela rozbita między stronami.
Nie każdą ofertę należy wysyłać bez udziału człowieka. Akceptacja jest wskazana, gdy handlowiec może swobodnie zmieniać zakres, warunki lub cenę. Powinna być też wymagana przy nietypowych zapisach.
System może najpierw wygenerować wersję roboczą i powiadomić osobę zatwierdzającą. Akceptacja uruchamia wysyłkę, a odrzucenie zwraca dokument do poprawy. Powód odrzucenia należy zapisać przy rekordzie.
Powtarzalne warianty można wysyłać automatycznie, jeśli warunki są jednoznaczne. Każde odstępstwo powinno kierować sprawę do człowieka.
Reguły akceptacji mogą zależeć od wartości oferty, wysokości rabatu lub warunków płatności. Po zmianie danych wcześniej zaakceptowana wersja nie powinna być automatycznie uznawana za aktualną. System musi utworzyć nową wersję. Jeśli zmiana dotyczy kontrolowanych pól, dokument powinien ponownie trafić do właściwej osoby.
Wiadomość e-mail również powinna powstawać z szablonu. Musi zawierać dane odbiorcy, temat, krótkie wyjaśnienie i właściwy dokument lub bezpieczny odnośnik.
Przed wysyłką system powinien sprawdzić adres odbiorcy i obecność załącznika. Trzeba też wskazać adres do odpowiedzi. Klient nie powinien trafiać na skrzynkę, której nikt nie obsługuje.
Po wysłaniu należy zapisać datę, odbiorcę, wersję dokumentu i wynik operacji. Błąd wysyłki powinien utworzyć zadanie, a nie pozostać tylko wpisem technicznym. Historia pozwala ustalić, co klient rzeczywiście otrzymał.
Wiadomość powinna być powiązana z konkretną szansą sprzedażową i identyfikatorem oferty. Jeśli dokument udostępniono jako odnośnik, trzeba zachować jego adres i zastosowane uprawnienia. Ponowna wysyłka powinna utworzyć nowe zdarzenie bez nadpisywania informacji o poprzedniej próbie. Ułatwi to wyjaśnienie błędu doręczenia i ustalenie, która wersja dotarła do odbiorcy.
Wysłanie dokumentu nie kończy procesu sprzedaży. CRM może utworzyć zadanie dla właściciela sprawy i powiązać je z ofertą. Po zapisaniu reakcji klienta zadanie powinno zniknąć lub zmienić status.
Termin zadania można wyliczyć od daty skutecznej wysyłki, a nie od rozpoczęcia generowania dokumentu. Właścicielem powinien pozostać handlowiec prowadzący daną szansę. Jeśli oferta ma datę ważności, przypomnienie musi pojawić się na tyle wcześnie, by kontakt nie nastąpił po wygaśnięciu warunków.
Ten etap można połączyć z procesem automatycznego przypominania handlowcom o leadach. Oba mechanizmy powinny korzystać z tych samych właścicieli, statusów i zasad zatrzymywania przypomnień.
Automatyczna wiadomość uzupełniająca nie zawsze będzie właściwa. Jeśli klient odpowiedział, odmówił lub poprosił o kontakt w innym terminie, system musi to uwzględnić.
Proces będzie zawodny, jeśli dane są wpisywane w różnych miejscach i bez wspólnego standardu. Nawet dobry szablon nie naprawi błędnej ceny, nieaktualnego adresu ani niejasnego zakresu.
Automatyzacja niewiele da przy ofertach tworzonych od podstaw dla każdego klienta. Jeśli większość treści wymaga analizy, negocjacji i fachowej oceny, system może przygotować szkic. Ostateczna decyzja nadal należy do człowieka.
Problemem jest także brak właściciela procesu. Ktoś musi odpowiadać za szablony, źródła danych, wyjątki i błędy wysyłki. Bez takiej osoby automatyzacja z czasem przestanie odpowiadać rzeczywistej ofercie firmy.
Nie należy automatyzować wysyłki, dopóki firma nie ustali sposobu wyceny. System jedynie przyspieszy istniejący chaos. Najpierw trzeba ujednolicić dane, warianty i zasady akceptacji.
Szczególnej kontroli wymagają dane osobowe, poufne warunki i dokumenty kierowane do konkretnych odbiorców. Dostęp do rekordów należy ograniczyć. Trzeba też zabezpieczyć proces przed wysłaniem oferty do niewłaściwej osoby.
Zagrożeniem jest użycie nieaktualnego szablonu. Zmiana cennika, zakresu lub warunków musi prowadzić do aktualizacji procesu. Należy zachować wersję dokumentu wykorzystaną przy danej wysyłce.
Przed wdrożeniem sprawdź uprawnienia kont używanych przez przepływ. Konto generujące dokument nie powinno mieć szerszego dostępu, niż wymaga proces. Trzeba również ustalić, co stanie się po wygaśnięciu hasła, odebraniu licencji lub zmianie właściciela integracji. Wysyłka nie może zatrzymać się bez powiadomienia.
Pomoc specjalisty jest potrzebna, gdy dane pochodzą z wielu systemów lub integracja wymaga obsługi nietypowych wyjątków. Dotyczy to też procesów z podpisem elektronicznym, rozbudowanymi uprawnieniami lub wymianą danych z systemem finansowym.
Konsultacja prawna lub księgowa może być konieczna, jeśli automatycznie wstawiane zapisy mają znaczenie umowne, podatkowe lub regulacyjne. Specjalista techniczny nie powinien sam rozstrzygać takich kwestii.
Wsparcie będzie również potrzebne, gdy błędna oferta może spowodować poważne skutki finansowe. Taki proces wymaga testów, rejestru zdarzeń, obsługi awarii i kontroli uprawnień.
Zacznij od jednego powtarzalnego rodzaju oferty. Opisz zdarzenie startowe, wymagane dane, wyjątki i osobę zatwierdzającą. Następnie przygotuj szablon i przetestuj go na różnych przypadkach.
Testy powinny objąć ofertę standardową, brak pola obowiązkowego, nietypowo długą nazwę klienta, rabat, odrzucenie akceptacji i błąd doręczenia. Ponownie edytuj też rekord wysłanej oferty, aby sprawdzić zabezpieczenie przed duplikatami. Wynik każdego scenariusza porównaj z oczekiwanym statusem w CRM i zapisanym plikiem.
Wysyłkę włącz dopiero po poprawnym przejściu całej ścieżki. Obserwuj błędy, duplikaty i ręczne poprawki. Jeśli wyjątki występują często, popraw dane lub warunki procesu, zamiast dodawać kolejne niejasne reguły.
System powinien przejąć składanie dokumentu i obsługę administracyjną. Decyzje wymagające oceny pozostają po stronie człowieka.
Tak, źródłem danych może być formularz, arkusz lub baza w innym systemie. Trudniej wtedy utrzymać historię klienta, status wysyłki i odpowiedzialność za dalszy kontakt. CRM nie jest konieczny, ale zwykle porządkuje cały proces.
Może, jeśli dane i warianty oferty są jednoznaczne, a wyjątki zostały dobrze opisane. Przy indywidualnych cenach lub nietypowych warunkach bezpieczniejsza jest wcześniejsza akceptacja. System powinien zatrzymać wysyłkę, gdy brakuje wymaganych danych.
Każdy dokument powinien otrzymać unikalny identyfikator i zapisany status wysyłki. Reguła musi sprawdzać ten status przed wykonaniem kolejnej operacji. Warto też rozróżnić ponowną wysyłkę od utworzenia nowej wersji.
Błąd doręczenia powinien wrócić do CRM i utworzyć zadanie dla właściciela sprawy. System nie powinien uznawać takiej oferty za skutecznie wysłaną. Po poprawieniu adresu można uruchomić kontrolowaną ponowną wysyłkę.
Nie. Powtarzalne oferty można tworzyć za pomocą reguł, pól i szablonów. AI może pomóc w przygotowaniu opisu lub podsumowaniu potrzeb, ale treści wpływające na cenę i zobowiązania powinny podlegać kontroli.
Newsletter
Klikając przycisk, zgadzasz się na kontakt w sprawie newslettera.