Workflow: Support Ticket Lifecycle

Modules involved: Support Tickets · Email Pipe · Spam Filters · Knowledge Base · Surveys
Who uses it: Echipa support, Agenți customer success, Clienți (portal)
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
  │     │  → spam filter → ticket nou SAU reply la existent
  │     │  (max 10 tichete / 15 min / expeditor — rate limiting)
  │
  ├── [PORTAL CLIENT]
  │     │  clientul deschide tichet din contul său
  │
  └── [MANUAL — de agent]
        │  agentul creează tichetul din `/admin/tickets`
        │
        ↓
[TICHET NOU]
  │  status: configurable (ex: New → In Progress → Answered → Closed)
  │  prioritate: Low / Medium / High / Urgent
  │  departament: alocat după adresa email destinație
  │
  ├── AGENT RĂSPUNDE
  │     │  reply adăugat → status actualizat
  │     │  clientul primește email cu răspunsul
  │     │  ↓ Client răspunde din email → reply adăugat automat via pipe
  │
  ├── RĂSPUNS PREDEFINIT
  │     │  agent selectează răspuns standard din bibliotecă
  │
  └── ESCALADARE
        │  prioritate crescută sau tichet transferat alt departament
        │
        ↓
[TICHET REZOLVAT]
  │  status → Answered / Closed
  │  ↓ opțional: articol Bază de Cunoștințe creat din soluție
  │  ↓ opțional: sondaj satisfacție trimis clientului
  │
[TICHET ÎNCHIS ✓]

Pas cu pas

1. Deschiderea tichetului — Sursele de intrare

A. Email Pipe (automat)

Cum funcționează:

  1. Un email ajunge pe adresa departamentului (ex: support@firma.ro)
  2. Serverul de mail redirecționează mesajul la /pipe.php din CRM
  3. Sistemul verifică filtrul spam (vezi mai jos)
  4. Dacă subiectul conține [Ticket ID: 123] → adaugă ca reply la tichetul existent
  5. 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:

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 spam@domain.com
subject Subiectul emailului *promotional*, *unsubscribe*
phrase Conținutul mesajului Cuvinte cheie spam

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

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

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:

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ă:

  1. Departamente — /admin/tickets/services — inclusiv adresa email dedicată per departament
  2. Statusuri — /admin/tickets/statuses — cu culori distinctive
  3. Priorități — /admin/tickets/priorities
  4. Răspunsuri predefinite — /admin/tickets/predefined_replies — top 10-20 situații frecvente
  5. Filtre spam — /admin/spam_filters/view/tickets — adrese și fraze cunoscute
  6. 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

Module implicate — documentație detaliată

← Înapoi la Workflows