Statuts et priorités

Les statuts et priorités permettent de suivre l'avancement des tickets et de prioriser les demandes.

Statuts de ticket

Cycle de vie complet

Workflow typique

OPEN → IN_PROGRESS → RESOLVED → CONFIRMED → CLOSED
           ↓              ↓
    PENDING_CUSTOMER   REOPENED → IN_PROGRESS

Transitions valides

Les transitions entre statuts suivent des règles strictes :

Note : RESOLVED ne peut aller que vers CONFIRMED ou REOPENED (flux de confirmation).

Priorités

Niveaux disponibles

Choisir la bonne priorité

LOW - Utilisez quand :

• La demande n'est pas urgente
• C'est une suggestion d'amélioration
• Le client peut attendre quelques jours

MEDIUM - Utilisez quand :

• C'est un cas de support standard
• L'impact est modéré
• Délai de résolution : 24-48h acceptable

HIGH - Utilisez quand :

• Le client est bloqué mais a un contournement
• C'est un client important (VIP, gros compte)
• L'impact business est significatif

URGENT - Utilisez quand :

• Blocage total, aucun contournement
• Perte de revenus en cours
• Problème de sécurité
• Nombreux clients impactés

Changer le statut ou la priorité

Via le tableau Kanban

1. Glissez-déposez la carte vers une autre colonne
2. Le statut est mis à jour automatiquement

Via le détail du ticket

1. Ouvrez le ticket
2. Cliquez sur le statut ou la priorité
3. Sélectionnez la nouvelle valeur

Via la vue liste

1. Cochez les tickets concernés
2. Utilisez les actions groupées

Règles métier importantes

Transitions bloquées

Certaines transitions sont impossibles :

• OPEN → CONFIRMED ❌ (doit passer par RESOLVED d'abord)
• RESOLVED → OPEN ❌ (seul CONFIRMED ou REOPENED possible)
• CONFIRMED → REOPENED ❌ (doit passer par CLOSED d'abord)

Si vous essayez une transition invalide, l'API retourne une erreur InvalidTicketStatusTransitionError.

Flux de confirmation (RESOLVED)

Quand un agent marque un ticket comme RESOLVED :

1. Un token de confirmation unique est généré
2. Les champs resolvedAt et resolvedByUserId sont enregistrés
3. Un message système TICKET_RESOLVED est envoyé dans la conversation avec un lien de confirmation
4. Le visiteur a deux choix :

Si le visiteur confirme :

• Le ticket passe en CONFIRMED
• Le champ confirmedAt est enregistré
• La conversation associée se ferme automatiquement
• Le token est invalidé

Si le visiteur conteste :

• Le ticket passe en REOPENED
• Les champs resolvedAt et resolvedByUserId sont réinitialisés
• La conversation reste ouverte
• Le token est invalidé

Règles importantes :

• Le token est à usage unique - une fois utilisé, il est invalidé
• Le token ne fonctionne que si le statut est RESOLVED - si le statut change entre temps, le token devient invalide
• Depuis RESOLVED, seules les transitions vers CONFIRMED ou REOPENED sont possibles

Synchronisation avec la conversation

Un seul ticket par conversation

Chaque conversation ne peut avoir qu'un seul ticket associé.

• Tentative de créer un 2e ticket → erreur TicketAlreadyExistsError

Assignation et SLA

Quand un ticket est assigné pour la première fois :

• Le timestamp assignedAt est enregistré
• Le chrono SLA d'assignation s'arrête
• La réassignation ne réinitialise PAS ce chrono

Synchronisation avec les trackers externes

Quand vous utilisez Linear, Jira, Trello ou Notion :

• Les changements de statut sont synchronisés automatiquement
• La synchronisation est bidirectionnelle (changement externe → Sonario)
• Un mapping de statuts est configuré par organisation

Priorité et SLA par défaut

Note : Les SLA ne se mettent jamais en pause, même si le ticket est en PENDING_CUSTOMER.