Strona główna -> Dokumentacja -> DTMF i menu

DTMF i menu: GetDTMF w praktyce

DTMF realizujesz akcją GetDTMF. Wynik wraca w kolejnym webhooku jako zdarzenie GetDTMF (w Event.EventData dostaniesz cyfry albo informację o timeout).

Najprostszy schemat

Play – krótka zapowiedź: co ma wpisać użytkownik.
GetDTMF – zbierasz cyfry (limit + timeout + zakończenie #).
Webhook wraca z wynikiem → walidujesz i podejmujesz decyzję.
Routing / komunikat – albo kierujesz do kolejki, albo podajesz informację.

DTMF działa najlepiej, gdy ma jedno zadanie na krok: “podaj ID”, “wybierz temat”, “oceń 1–5”.

Przykład: pytanie o ID sprawy

Wariant “klasyczny”: prosisz o numer zgłoszenia/zamówienia, a potem sprawdzasz go w systemie.

{
  "Action": { "Type": "GetDTMF", "Prompt": "1", "Timeout": "1200", "MaxDigits": "12" },
  "Session": { "step": "ask_ticket_id", "tries": 0 }
}

Po GetDTMF dostaniesz kolejne zdarzenie z Event.EventName = GetDTMF oraz danymi w Event.EventData.

Akcje i parametry: Akcje API.

Wzorzec produkcyjny: próby, walidacja i fallback

Timeout → powtórz pytanie (ale max 2–3 razy).
Błędny format (za krótko/za długo) → komunikat “spróbuj ponownie”.
Limit prób → przejście do kolejki/konsultanta (żeby nie frustrować).
Session trzyma licznik tries i etap step.

Jeśli zbierasz dane wrażliwe (np. identyfikator klienta), nie powtarzaj ich w komunikacie. Jeśli musisz, maskuj (np. ostatnie 2–3 cyfry).

DTMF jako “menu” (wybór ścieżki)

DTMF świetnie sprawdza się też jako krótkie menu (1–4), zamiast budowania długich drzew IVR. Wtedy GetDTMF ma zwykle MaxDigits = 1, a decyzja jest natychmiastowa.

1 – sprzedaż
2 – serwis
3 – rozliczenia
timeout – domyślna kolejka (bez “ślepego końca”)

Chcesz gotowy wzorzec “state machine” z DTMF?

W przykładach kodu masz flow: Play → GetDTMF → walidacja → routing + retry + fallback.

Przykłady kodu Stabilność