# Support — Airtable Customer Service

Référence pour les skills qui manipulent la base Airtable **Customer Service** (création de tickets support, mise à jour après création d'issue GitLab ou de MR).

## Identifiants fixes

| Resource | ID |
|---|---|
| Base « Customer Service » | `app79vpJ07qFIOEm1` |
| Table « Tickets support » | `tblHjCvyOcdq0Kw0z` |
| Table « Contacts » | `tblsA80YLd7cMOjoV` |
| Table « Comptes » | `tblbQQyq0RLodDcEb` |

## Champs clés de la table Tickets support

| Champ | Type | Rôle |
|---|---|---|
| Nom | text | Titre court du ticket |
| Status | select | Toujours « Ouvert » à la création |
| Contact | link | Lien vers Contacts (par email) |
| Compte | link | Lien vers Comptes (par `group_id` → nom du réseau) |
| Sujet | select | OP, Driver, Info, Screen, Editor, API, INFRA (voir [support-vocabulary.md](support-vocabulary.md)) |
| Responsable | single select | Toujours « Patrick LEMOS CAIXAS » |
| Criticité | number (1-5) | Sévérité technique — toujours sous-estimer |
| Impact | number (1-5) | Portée terrain |
| Date déclaration | date | Jour de création |
| Notes | multilineText | 3 sections : observations Patrick / pré-analyse Claude / liens utiles |
| Ticket Gitlab | multilineText (ID `fldjuMRjWBX0XiQjm`) | URL(s) de l'issue puis de la MR associée |

**Règle d'or** : toujours éviter les tickets avec **8+ étoiles cumulées** (criticité + impact). Sous-estimer plutôt que sur-estimer. N'atteindre 8+ que si c'est réellement inévitable.

## Grilles Criticité & Impact

### Criticité (/5 — sévérité technique)

| Niveau | Label | Définition |
|---|---|---|
| 1/5 | Cosmétique | Visuel/ergonomie, pas d'impact fonctionnel |
| 2/5 | Mineure | Fonctionnalité secondaire partiellement dégradée |
| 3/5 | Moyenne | Fonctionnalité principale impactée, contournement possible |
| 4/5 | Élevée | Fonction critique partiellement bloquée, risque de régression |
| 5/5 | Bloquante | Fonction critique totalement indisponible |

### Impact (/5 — portée terrain)

| Niveau | Label | Définition |
|---|---|---|
| 1/5 | Faible | Un utilisateur isolé, contournement facile |
| 2/5 | Modéré | Quelques utilisateurs ou un client, cas occasionnel |
| 3/5 | Significatif | Plusieurs clients ou cas récurrents gênants |
| 4/5 | Critique | Beaucoup de clients impactés, dégradation notable |
| 5/5 | Majeur | Tous les utilisateurs et clients bloqués |

## URL interface Airtable (obligatoire dans les issues GitLab)

Les devs n'ont **pas accès à la vue directe de la table** Airtable — ils n'ont que l'interface. Quand on crée une issue GitLab depuis un ticket Airtable, on injecte toujours dans la description une URL pointant vers l'interface avec le `rowId` du ticket :

### Construction (Python)

```python
import base64
import json

record_id = "recXXXXXXXXXXXXXX"  # le record ID du ticket

detail = {
    "pageId": "pagiTMfXP0g7uB3Gy",
    "rowId": record_id,
    "showComments": False,
    "queryOriginHint": {
        "type": "pageElement",
        "elementId": "pelkGg0nsu8cYV6HU",
        "queryContainerId": "peliBPo9hEgj93iqw",
        "savedFilterSetId": "sfseprUWUd2ZZzBAs",
    },
}
detail_b64 = base64.urlsafe_b64encode(
    json.dumps(detail, separators=(",", ":")).encode()
).decode().rstrip("=")

url = f"https://airtable.com/app79vpJ07qFIOEm1/pagYe4tpe7bie8LES?detail={detail_b64}&93iqw=sfseprUWUd2ZZzBAs"
```

### IDs fixes de l'interface Tickets support

| ID | Valeur |
|---|---|
| baseId | `app79vpJ07qFIOEm1` |
| interfacePageId | `pagYe4tpe7bie8LES` |
| inner pageId | `pagiTMfXP0g7uB3Gy` |
| elementId | `pelkGg0nsu8cYV6HU` |
| queryContainerId | `peliBPo9hEgj93iqw` |
| savedFilterSetId | `sfseprUWUd2ZZzBAs` |

Seul `rowId` change d'un ticket à l'autre.

## Structure « Notes » (3 sections)

La Notes d'un ticket Airtable contient **toujours** 3 sections :

1. **Observations Patrick** — depuis Intercom ou son message : ses tests, appels API testés, URLs, captures, comportement observé. C'est la **preuve de première main**, jamais la couper.
2. **Pré-analyse Claude** — sortie du skill `support-bug-investigate` (Bug resume / Cause racine / Chemin d'exécution / Quoi faire).
3. **Liens utiles** — pour que les devs puissent reproduire :
   - Datadog logs (URL avec le query construit)
   - API en erreur (endpoint exact depuis Datadog)
   - Conversation Intercom
   - Fichier(s) source GitLab concernés
