csbot-prototype/documentation/06-tickety.md

06 - Tickety

Co ticket je a co neni

Ticket je prichozi pozadavek odkudkoliv. Prisla zprava na WhatsApp, Messenger nebo Instagram, prisel e-mail, nekdo zavolal na hlasovou linku, odeslal formular. Z toho vznikne ticket, ktery ma sveho cloveka a dohledatelny prubeh.

Ticket neni bug ani wish. Vyvojarska agenda je jina vec s jinym zivotnim cyklem a v prototypu zatim neexistuje. Michat je do jedne evidence by znamenalo, ze ani jedna nefunguje poradne.

Tri veci, na kterych to stoji

Kanaly ustuji do ticketu. WhatsApp, e-mail, hlasova linka a formular jsou plnohodnotne spoustece. Automatizace zacne prichozi zpravou a skonci zalozenym ticketem.

Ticket ma sveho cloveka. assignee neni volny text, ale odkaz na konkretniho resitele. Da se rict "hod to na Karla Vomacku" a Karel to ma mezi svymi tickety. Nad tym je prehled pres cely tym, kde je videt, kdo co u sebe ma.

Kazdy ticket je dohledatelny. Nese si strom zaznamu o tom, co se s nim delo a co ktera sluzba vratila. Kdyz neco nesedi, neni potreba hadat.

Datovy model

src/data/ticketStore.ts

interface Ticket {
  id: string;
  subject: string;
  body: string;              // cely text pozadavku, prazdny = krok ho nenaplnil
  sourceRef: string | null;  // odkaz na zdrojovou zpravu u poskytovatele
  channel: 'whatsapp' | 'email' | 'voice' | 'form' | 'portal';
  customer: TicketCustomer;
  status: 'new' | 'open' | 'waiting' | 'resolved';
  priority: 'low' | 'normal' | 'high' | 'critical';
  assignee: { id: string; name: string } | null;   // null = ceka ve fronte
  automationId: string | null;                     // null = zalozeno rucne
  createdAt: string;
  updatedAt: string;
}

interface TicketCustomer {
  id: string | null;    // null = firmu se nepodarilo dohledat v CRM
  company: string;
  contact: string;
  reply: string;        // adresa nebo cislo, kam se odpovida
}

customer.id je zamerne nullable. Prave na nej se pta podminka "mame zakaznika?" ve strome automatizace. Bez toho by nesla postavit vetev "firmu neznam, zaloz obchodni pripad a nekomu to dej".

subject je kratke shrnuti do seznamu, body je cely text pozadavku. Do body patri telo e-mailu, zprava z WhatsApp nebo prepis hovoru. Kdyz je prazdne, znamena to, ze krok "Zalozit ticket" nemel nastavene pole Obsah - detail ticketu to napise nahlas misto toho, aby ukazal prazdne misto.

Uvnitr ulozista se drzi jen assigneeId, jmeno se dopocitava pri cteni. Kdyz resitel ze seznamu zmizi, ticket nespadne - jen se zaloguje a tvari se jako neprirazeny.

Resitele

src/data/people.ts

Resitel je oddeleny od uzivatele. Uzivatel je ten, kdo se prihlasi do portalu, resitel je ten, na koho jde ticket. Casto je to tyz clovek, ale ne vzdy - technik muze mit tickety a do portalu se nikdy neprihlasit.

Spojka mezi obojim je e-mail. Podle ni funguje filtr "moje tickety" (?assignee=me). Kdyz prihlaseny ucet zadnemu resiteli neodpovida, filtr se v portalu nabidne jako nedostupny misto toho, aby vracel prazdno bez vysvetleni.

Kazdy resitel ma capacity, tedy pocet nevyrizenych ticketu, ktery je pro nej jeste zdrava zatez. Neni to limit, nic se podle nej neodmita - jen se v prehledu oznaci, kdo je nad ni.

Prehled nad firmou

GET /api/dashboard/tickets/workload vraci pres cely tym: kolik ma kdo nevyrizenych, kolik celkem, kolik kritickych, jak stary je jeho nejstarsi ticket a jestli je nad kapacitu. K tomu pocet ticketu ve fronte bez resitele.

V portalu je to postranni panel na strance Tickety. Radek je zaroven filtr seznamu - kliknutim na cloveka se seznam zuzi na jeho tickety. Bez toho by to byl jen obrazek.

Sirka pruhu se pocita proti nejvytizenejsimu clenovi tymu, ne proti kapacite. Jde o porovnani lidi mezi sebou.

Log ticketu

Log je strom, ne seznam. Vetev podminky visi na zaznamu te podminky, takze je videt i to, ktera cast behu se vubec nespustila.

interface TicketTraceEntry {
  id: string;
  parentId: string | null;      // null = hlavni sekvence
  kind: 'trigger' | 'action' | 'condition' | 'note';
  connectorId: string | null;   // ktera sluzba to byla
  operationId: string | null;
  label: string;
  status: 'ok' | 'error' | 'skipped' | 'info';
  response: string | null;      // co sluzba vratila
  durationMs: number | null;
  at: string;
}

response je duvod, proc log existuje. V portalu se zobrazuje rovnou, ne po rozkliknuti - kvuli nemu se do logu chodi.

Zapisuje se zanorene (TraceInput s children) a uklada zplostele s parentId. Klient si strom zase poskladá. Zaznam s neznamym rodicem se nezahodi, prida se do korene a zaloguje - ztratit radek logu je horsi nez ho ukazat spatne zanoreny.

Komentare jsou taky zaznamy logu (kind: 'note'). Diky tomu je vsechno na jedne casove ose a nemusi se nikde skladat dohromady dva ruzne seznamy.

Konektor Tickety

Kategorie servicedesk, driv byl pod Nastroji. Ma obe strany:

Spoustec	Kdy
created	zalozen ticket, at uz z kanalu nebo rucne
unknown-customer	k ticketu se nepodarilo dohledat firmu
assigned	ticket dostal konkretniho cloveka
status-changed	prechod do jineho stavu vcetne vyreseni

Akce	Co dela
create	zalozi pozadavek
assign	preda ticket cloveku
set-status	posune stav
link-customer	doplni firmu z CRM
comment	zapise komentar do logu

Typicky retez, ktery z toho jde postavit:

Prijata zprava z WhatsApp
  Zaradit do kategorie          (AI)
  Dohledat firmu podle telefonu (CRM)
  knownCustomer?
    ANO  Zalozit ticket, Priradit resiteli
    NE   Zalozit ticket, Zalozit obchodni pripad, Upozornit servicedesk

Co se ticketu preda

Akce "Zalozit ticket" ma nastavitelna pole. Klikni na krok ve strome a vyplnis je primo tam. Hodnota je sablona: {{nazev}} se nahradi parametrem spoustece.

Pole	Typicka hodnota u WhatsApp
Predmet	Zprava od {{profileName}}
Obsah	{{text}}
Firma	necha se prazdne, doplni CRM krok
Kontakt	{{profileName}}
Odpoved na	{{phone}}
Priorita	vyber ze seznamu
Resitel	vyber ze seznamu lidi

Nabidka parametru je pod poli. Kliknuti vlozi {{nazev}} na pozici kurzoru, takze se nemusi psat rucne a neudela se preklep.

Vyber resitele se plni ze seznamu v people.ts, ne z rucne psaneho ID. Novy clovek v tymu se v nabidce objevi sam.

Co je kde videt

Krok vidi parametry spoustece plus vystupy vsech kroku, ktere jsou pred nim. Diky tomu jde do stromu vlozit predvalidaci a vetvit se podle jeji odpovedi.

Dve pravidla:

• krok vidi to, co je pred nim ve stejne sekvenci, a to, co videl jeho rodic,
• vetev podminky nepridava nic do sekvence za podminkou. Vetev nemusela probehnout, spolehat se na jeji vystup by byla past.

Vystupy akci deklaruje katalog v outputFields. Ma je napriklad "Dohledat firmu" (customerKnown, companyId, companyName), "Zaradit do kategorie" (category, confidence) nebo "Zalozit ticket" (newTicketId).

Vypocet je v src/data/flowScope.ts, kopie pro UI v web/src/lib/flow.ts.

Jak udelat podminku

Tri ruzne pripady, kazdy se resi jinak.

Na prichozi zpravu. text je parametr spoustece, funguje rovnou:

Prijata zprava z WhatsApp
  text obsahuje "faktura"
    ANO  ...

Na vysledek mezikroku. Tohle je ta predvalidace. Krok "Dohledat firmu" vrati customerKnown a podminka se na nej zepta:

Prijata zprava z WhatsApp
  Dohledat firmu       Telefon {{phone}}
  customerKnown je splneno
    ANO  Zalozit ticket   Firma {{companyName}}, Obsah {{text}}
    NE   Zalozit ticket   bez firmy
         Zalozit obchodni pripad

{{companyName}} je uvnitr vetve dostupne, protoze krok "Dohledat firmu" je pred podminkou. Presne tenhle strom je ve vzorovych automatizacich.

Na obsah uz zalozeneho ticketu. Ve stejnem strome nejde, ticket v tu chvili teprve vznika a "Zalozit ticket" vraci jen newTicketId, ne cely ticket. Dela se druhou automatizaci se spoustecem "Zalozen ticket":

Zalozen ticket
  assigned neni splneno
    ANO  body obsahuje "faktur"
           ANO  Priradit resiteli   ID {{ticketId}}, Martin Kriz
           NE   body obsahuje "voicebot"
                  ANO  Priradit   Eva Novakova
                  NE   Priradit   Karel Vomacka

Rozdeleni neni obchazeni omezeni, ale zamer. Prijem z kanalu je jedna automatizace na kanal, smerovani je jedna spolecna nad vsemi tickety.

Vzorove automatizace

V automationStore.ts jsou nasazene presne v tomhle rozdeleni:

Automatizace	Co ukazuje
WhatsApp: zprava do ticketu	predvalidace v CRM a vetveni podle vysledku
Facebook: zprava do ticketu	prijem bez predvalidace, nemame podle ceho hledat
E-mail: pozadavky do ticketu	dohledani podle {{from}}, plus odpoved zadavateli
Smerovani ticketu na resitele	jedna spolecna logika nad vsemi tickety

Prijmove automatizace zamerne neprirazuji resitele. Nechavaji ticket ve fronte a smerovani si ho prevezme. Podminka assigned neni splneno na zacatku smerovani zaridi, ze rucni prirazeni se neprepise.

Sablony

Odkazuje se jmenem parametru ({{subject}}), ne jeho ID. Jmeno uzivatel vidi a pise, {{f_42}} by nikdo neprecetl.

Cenou je, ze prejmenovani parametru sablonu rozbije. Proto se to hlida:

• builder podtrhne pole a napise, ktery parametr chybi,
• server to vraci mezi issues, tedy jako nedodelek, ne jako chybu. Rozdelana prace se ulozi, jen automatizace nepujde zapnout.

Naopak chyba (400) je nastaveni pole, ktere akce v katalogu nema. To uz neni nedodelek, ale rozbity strom - ulozit ho by znamenalo drzet data, ktera nikdo neprecte.

Chybejici parametr se pri behu dosadi jako prazdny retezec a zaloguje. Nechat v textu {{neco}} by znamenalo poslat to zakaznikovi.

Akce, ktere inputs zatim nemaji, to v builderu napisou primo na karte kroku. Lepsi nez nechat cloveka hledat nastaveni, ktere neexistuje.

Parametry od sluzby

Nektere spoustece si data urcuji samy. E-mail posila from, subject, body. WhatsApp posila phone, text. Ticket posila knownCustomer. Uzivatel si je nevymysli, ale potrebuje nad nimi stavet podminky.

Katalog je proto deklaruje v providedFields u operace. Chovaji se pak takhle:

• builder je ukazuje jen ke cteni, pridat ani prejmenovat nejdou,
• server je pri ulozeni stromu vzdy dosadi z katalogu a to, co poslal klient, zahodi (normalizeTriggerFields v src/routes/dashboard.ts),
• dosazeni probiha pred validaci, jinak by podminky odkazujici na katalogova ID vypadaly jako rozbite.

ID techto parametru (email.from, ticket.knownCustomer) musi zustat stabilni. Odkazuji se na ne podminky v ulozenych stromech, prejmenovani ID je rozbije.

Spoustece bez providedFields (webhook, formular) funguji jako predtim - parametry si deklaruje uzivatel.

Stranky portalu

/dashboard/tickety       seznam, filtry, prehled vytizeni
/dashboard/tickety/:id   detail: prubeh a log, resitel, zakaznik, puvod

Otevrene rozhodnuti pro runtime

Model nema zadne "prvni shoda vyhrava". Vsechny automatizace se stejnym spoustecem se spusti, vsechny. Podminka je uvnitr stromu, ne na spousteci, takze automatizaci nezastavi pred prvnim krokem.

Doporucene rozdeleni (jedna automatizace na kanal, jedna spolecna na smerovani) na to nenarazi, protoze kazdy prijem ma jiny spoustec a smerovani je jen jedno. Problem vznikne, jakmile nekdo udela vic automatizaci nad stejnym spoustecem:

• tri automatizace na "Prijat e-mail", kazda s jinym obsahuje, udelaji z jednoho e-mailu tri tickety,
• dve smerovaci automatizace provedou dve prirazeni a poradi neni dane.

Dnes se to neprojevi, protoze runtime neexistuje. Az se bude psat, je potreba to rozhodnout vedome, ne omylem. Varianty od nejlevnejsi:

1. Nechat jak je a drzet se pravidla jedna automatizace na spoustec. Funguje dnes, nic se nemeni, ale nikdo to nevynucuje.
2. Filtr na spousteci. Automatizace by umela rict "tenhle e-mail neni muj" jeste pred prvnim krokem. Umozni jednu automatizaci na pravidlo.
3. Poradi a prvni shoda vyhrava. Nejmocnejsi, ale chovani zavisle na neviditelnem poradi se spatne ladi. Nedoporucuje se.

Co chybi

Chybi	Poznamka
Bugs a wishes	vyvojarska agenda, samostatna evidence
Skutecny beh automatizaci	sablony se ukladaji, ale nikdo je nevyhodnocuje
inputs u zbylych konektoru	zatim ticket, kanaly, CRM a AI, ostatni maji jen napovedu
Napojeni logu na beh	automationId je odkaz, historie behu ale neexistuje
Odpoved zakaznikovi z detailu	akce send u kanalu se z portalu nevola
SLA a eskalace	zadne lhuty, capacity je jen orientacni
Databaze	data v pameti, restart je vrati na vychozi sadu