Workflow: Support Ticket Lifecycle

Modules involved: Support Tickets · Email Pipe · Spam Filters · Knowledge Base · Surveys · WhatsApp · Appointly (Callbacks) · Portal Client · Tasks · Workflow Automation · Announcements
Who uses it: Agent Suport L1, Team Lead Suport, Manager Suport, Clienți (portal + email + WhatsApp)
Durata tipică: Ore – zile (depinde de complexitatea problemei)

Overview

Ciclul complet al unui tichet de suport: de la deschidere (email automat, portal client sau manual de agent) până la rezolvare și feedback. Include filtrarea spam, rutarea pe departamente, urmărirea răspunsurilor, și opțional alimentarea bazei de cunoștințe cu soluțiile găsite.

Diagrama fluxului

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SURSE DE TICHETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  │
  ├── [EMAIL → PIPE.PHP]
  │     │  email primit pe adresa departamentului (ex: [email protected])
  │     │  → spam filter → tichet nou SAU reply la tichet existent [Ticket ID: X]
  │     │  rate limiting: max 10 tichete / 15 min / expeditor
  │     │  rutare automată pe departament după adresa To:
  │
  ├── [PORTAL CLIENT] /authentication/login
  │     │  clientul logat completează formularul → departament, subiect, atașamente
  │     │  clientul vede istoricul tuturor tichetelor sale
  │     │  poate adăuga reply-uri fără email
  │
  ├── [WHATSAPP INBOX]
  │     │  mesaj primit → agentul vede în /admin/whatsapp inbox
  │     │  număr identificat → mapat la Lead / Contact existent
  │     │  număr necunoscut + auto-lead activ → Lead creat automat
  │     │  ⚠ Tichetul se creează MANUAL de agent din conversație
  │
  └── [MANUAL — de agent]
        │  din /admin/tickets → Adaugă — la telefon, chat intern, cerere verbală
        │
        ↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TICHET NOU CREAT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  │  status: New (sau configurat implicit)
  │  prioritate: Low / Medium / High / Urgent
  │  departament: alocat automat (email) sau manual
  │
  ├── [AUTOMATIZARE NOTIFICARE] ← Workflow Automation
  │     Trigger: Tichet Nou + Prioritate = Urgent
  │     Acțiune: notificare push + email → Team Lead imediat
  │
  ├── AGENT REVIZUIEȘTE CONTEXTUL
  │     │  deschide fișa clientului → istoricul complet:
  │     │  → tichete anterioare, facturi, comenzi, contracte, oportunități
  │     │  cauți soluția în Knowledge Base înainte să scrii
  │
  ├── RĂSPUNS AGENT
  │     │  cu Răspuns Predefinit (bibliotecă) SAU redactat manual
  │     │  + atașamente + notă internă (invizibilă clientului)
  │     │  status după trimitere: Answered / In Progress / On Hold
  │     │  clientul primește email automat cu răspunsul
  │     │  ↓ Client răspunde din email → pipe.php → reply automat la tichet
  │     │  ↓ Client răspunde din portal → reply adăugat → notificare agent
  │
  ├── CALLBACK PROGRAMAT (dacă problema necesită apel)
  │     │  din tichet → Appointly → programare callback
  │     │  data, ora, agent responsabil, reminder -30 min
  │     │  agent sună → documentează soluția în tichet
  │     │  marchează programarea ca Finished
  │
  ├── TASK LEGAT DE TICHET
  │     │  dacă rezolvarea necesită un pas intern:
  │     │  → creezi Task atașat tichetului
  │     │  → asignezi colegului responsabil (IT, Depozit, Financiar)
  │     │  → tichetul rămâne open până task-ul e completat
  │
  └── ESCALADARE
        │  agentul schimbă: departamentul / agentul alocat / prioritatea
        │  adaugă notă internă cu tot ce a investigat
        │  ↓ Automatizare: Tichet fără reply staff > 4h → alertă Team Lead
        │
        ↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FLUXURI CROSS-DEPARTAMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  │
  ├── Dispută factură → Contabil AR (Financiar)
  │     Suportul documentează → pasează → urmărește → informează clientul
  │
  ├── Problemă livrare / retur → Depozit
  │     Verifici AWB din fișa clientului → crezi Retur Livrare dacă e cazul
  │
  ├── Oportunitate comercială → Vânzări / KAM
  │     Clientul reclamant e deschis la o alternativă → crezi oportunitate CRM
  │
  └── Bug tehnic → IT / Admin
        Documentezi: pași reproducere, eroare exactă, versiune
        → Task pentru IT → informezi clientul cu ETA
        │
        ↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REZOLVARE ȘI VALORIFICARE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  │
  ├── Status → Closed
  │     clientul primește notificare de închidere
  │
  ├── Articol Knowledge Base (dacă soluția e valoroasă)
  │     Team Lead / Agent → KB → Adaugă Articol
  │     Titlu ca întrebare → pași clari → publică pentru clienți
  │
  ├── Survey CSAT (automat via Workflow Automation)
  │     Trigger: Closed → Wait 1h → trimite survey → emailul clientului
  │     Răspunsurile → /admin/surveys → Rezultate
  │
  └── Închidere automată (Workflow Automation)
        Trigger: Answered + fără activitate > 7 zile
        Acțiune: Status → Closed + notă automată
        Redeschidere: client trimite email → pipe.php → Status → Open

[TICHET FINALIZAT ✓ · KB ÎMBOGĂȚIT · CSAT COLECTAT]

Pas cu pas

1. Deschiderea tichetului — Sursele de intrare

A. Email Pipe (automat)

Cum funcționează:

Un email ajunge pe adresa departamentului (ex: [email protected])
Serverul de mail redirecționează mesajul la /pipe.php din CRM
Sistemul verifică filtrul spam (vezi mai jos)
Dacă subiectul conține [Ticket ID: 123] → adaugă ca reply la tichetul existent
Dacă nu → creează tichet nou cu datele expeditorului

Rate limiting: Maxim 10 tichete noi / 15 minute per adresă de email — previne flood-ul.

Opțiuni configurabile în email pipe:

Opțiune	Descriere
`email_piping_only_registered`	Acceptă tichete doar de la emailuri înregistrate ca clienți
`email_piping_only_replies`	Acceptă doar reply-uri la tichete existente (nu creează tichete noi)
`email_piping_default_priority`	Prioritatea implicită pentru tichete din email
`default_ticket_reply_status`	Statusul implicit la adăugarea unui reply (default: `3` = Answered)

Rutarea pe departamente:
Departamentul tichetului este determinat automat de adresa To: din email — fiecare departament are o adresă unică configurată în setări.

B. Portal Client

Clientul logat în portalul propriu completează formularul de tichet:

Subiect + descriere
Departament (dropdown)
Prioritate (dacă e permisă selecția)
Atașamente

C. Manual de agent

Din /admin/tickets → Adaugă Tichet — agentul completează toate câmpurile inclusiv clientul asociat.

2. Filtrare Spam

Unde: /admin/spam_filters/view/tickets

Înainte de crearea tichetului din email, sistemul verifică trei tipuri de filtre:

Tip filtru	Câmp verificat	Exemple
`sender`	Adresa email expeditor	`[email protected]`
`subject`	Subiectul emailului	`promotional`, `unsubscribe`
`phrase`	Conținutul mesajului	Cuvinte cheie spam

Subiecte blocate automat (hardcodate în pipe.php):

Mail delivery failed
failure notice
Returned mail
Undelivered Mail

Dacă un filtru e activat și se potrivește → emailul e ignorat (nu se creează tichet).

3. Structura tichetului

Câmpuri cheie (tbltickets):

Câmp	Note
`ticketid`	ID unic
`subject`	Titlul problemei
`message`	Descrierea inițială
`status`	FK → `tbltickets_status` (user-configurable)
`priority`	FK → `tbltickets_priorities`
`department`	FK → `tbldepartments`
`userid` / `contactid`	Clientul asociat
`email` / `name`	Expeditor extern (dacă nu e client înregistrat)
`admin`	Staff-ul alocat
`service`	Categoria serviciului (opțional)
`lastreply`	Timestamp ultimul răspuns — pentru măsurarea SLA informal
`adminread` / `clientread`	Flags citit/necitit de fiecare parte

Statusuri: Complet configurabile din /admin/tickets/statuses. Exemple uzuale:

Status tipic	Descriere
New	Tichet nou, neasignat
In Progress	Lucrat de un agent
Answered	Agent a răspuns — așteaptă clientul
On Hold	Suspendat (așteptare informații externe)
Closed	Rezolvat și închis
Spam	Marcat spam manual

Priorități: /admin/tickets/priorities

Valoare	Prioritate
`0`	Low
`1`	Medium
`2`	High
`3`	Urgent

4. Gestionarea tichetului — Răspunsuri și escaladare

Adăugare reply de agent

Unde: Din tichetul deschis → câmpul de reply

Agentul scrie răspunsul sau selectează un Răspuns Predefinit din bibliotecă
Poate atașa fișiere
Selectează statusul după trimitere (ex: Answered, On Hold)
Clientul primește automat emailul cu răspunsul

Replay predefinit (/admin/tickets/predefined_replies):
Bibliotecă de răspunsuri standard pentru situații frecvente — agent le inserează cu un clic, economisind timp și asigurând consistența comunicării.

Reply de client (din email)

Clientul dă Reply la emailul primit → pipe.php identifică [Ticket ID: X] din subiect → adaugă automat ca reply la tichet → notificare agent.

Reply de client (din portal)

Clientul intră în portal → vede tichetul → adaugă reply → notificare agent.

Escaladare

Nu există SLA automat, dar agentul poate:

Schimba prioritatea (Low → Urgent)
Schimba departamentul (retransfer)
Schimba agentul alocat
Adăuga notă internă (vizibilă doar staff, nu clientului)

5. Închiderea și valorificarea tichetului

Marcare Closed

Agentul schimbă statusul → Closed. Clientul primește notificare de închidere.

Creare articol Bază de Cunoștințe

Dacă soluția găsită e valoroasă pentru alți utilizatori → buton Adaugă la Knowledge Base din tichetul rezolvat.

Unde se publică: /admin/knowledge_base — articolele sunt indexate și căutabile de toți utilizatorii sau clienții portalului (per configurație vizibilitate).

Sondaj de satisfacție (opțional)

La închiderea tichetului → trigger automat via Workflow Automation → survey trimis clientului (din modulul Surveys).

Exemplu de automatizare:

Trigger: Ticket status → Closed
Wait: 1 oră
Action: Trimite survey "Satisfacție Suport" la emailul clientului

Ce se creează automat

Eveniment	Se creează automat
Email primit pe adresa departamentului	Tichet nou cu departament, prioritate și client detectate automat
Email cu `[Ticket ID: X]` în subiect	Reply adăugat la tichetul existent
Reply agent trimis	Email notificare client cu conținutul răspunsului
Reply client primit	Notificare agent; `lastreply` actualizat; `adminread = 0`
Tichet închis	Notificare client; opțional survey trigger

Configurare recomandată inițială

Înainte de a activa email pipe, configurează:

Departamente — /admin/tickets/services — inclusiv adresa email dedicată per departament
Statusuri — /admin/tickets/statuses — cu culori distinctive
Priorități — /admin/tickets/priorities
Răspunsuri predefinite — /admin/tickets/predefined_replies — top 10-20 situații frecvente
Filtre spam — /admin/spam_filters/view/tickets — adrese și fraze cunoscute
Email pipe — configurează forwarding pe serverul de mail către pipe.php

Puncte unde fluxul poate bloca

Problemă	Cauză probabilă	Soluție
Emailurile nu creează tichete	Pipe.php neconectat sau CRON inactiv	Verifică forwarding email + CRON job pentru pipe
Tichetul nou merge la departament greșit	Adresa `To:` nu corespunde niciunui departament	Actualizează adresele email în `/admin/departments`
Clientul primește loop de emailuri	Adresa departamentului = adresa de reply CRM	Verifică că adresele de trimitere și primire sunt diferite
Reply-urile externe nu se atașează tichetului	`[Ticket ID: X]` șters din subiect de clientul emailului	Instruiește clienții să păstreze subiectul; sau activează matching pe email sender
Prea multe tichete spam	Filtre spam neconfigurate	Adaugă sendere și fraze în `/admin/spam_filters`
Agentul nu vede tichetul	Tichetul e pe alt departament fără acces	Verifică permisiunile departamentului din rolul agentului

Rapoarte relevante

Raport Knowledge Base — /admin/reports/knowledge_base_articles — articole per vizualizări
Audit Tichete — /admin/utilities/pipe_log — log-ul pipe.php cu toate emailurile procesate
Statistici Tichete — volum pe departament, prioritate, status, timp de răspuns

Module implicate — documentație detaliată

← Înapoi la Workflows

Tip

Setați statusul "Așteptare Client" când un tichet așteaptă răspunsul clientului — acesta oprește ceasul SLA de partea voastră astfel rapoartele de breach SLA reflectă cu acuratețe timpul de răspuns al echipei dvs., nu întârzierea clientului.

Note

Răspunsurile predefinite și linkurile la articolele KB împreună deflectează contactele repetate. Când rezolvați o problemă frecventă, actualizați simultan articolul KB și răspunsul predefinit — ambele canale (autoservire și agent) beneficiază de rezoluție.