# Décisions à valider avec ADVMFR (client)

> Liste des choix produit / config en attente d'une décision du client (Advance Manufacturers),
> avant go-live. Chaque item : recommandation + alternatives + valeur par défaut si pas de réponse.
> Mettre à jour le statut au fur et à mesure.

## 1. Accusé de réception automatique  *(statut : OUVERT)*

**Question** : envoie-t-on un accusé de réception automatique au client à l'arrivée d'un mail
(« nous avons bien reçu votre demande » + n° de ticket) ?

- **Contexte** : les auto-replies natifs Zammad sont **désactivés** (cf. `seed_triggers.rb`). Un
  accusé reste possible via un trigger « send email » sur nouveau ticket.
- **Recommandation** : accusé **minimal en anglais** avec n° de ticket, **excluant les expéditeurs
  auto/no-reply** (anti-boucle). Courant et apprécié en B2B bijouterie.
- **Alternative** : pas d'accusé (évite tout risque de backscatter/boucle ; le client peut trouver
  ça trop « automatique »).
- **Si retenu** : trigger condition = nouveau ticket + `from` ∉ no-reply/mailer-daemon ; perform =
  email au customer avec sujet `[Ticket#...]` et corps court (sans marqueurs IA, ton ADVMFR).
- **Défaut si pas de réponse** : **rester désactivé** (état actuel).

## 2. Horaires ouvrés du calendrier  *(statut : PROVISOIRE)*

- Actuel (instance test) : **Lun→Dim 08:00-20:00, Asia/Bangkok** (cf. `seed_calendar_sla.rb`).
- À **confirmer** : vrais horaires d'ouverture (non publiés sur le site) + **jours fériés thaï**
  (à ajouter via `ical_url` du calendrier).

## 3. Objectif SLA  *(statut : PROVISOIRE)*

- Actuel : **1re réponse 8h ouvrées** sur les 7 groupes.
- À confirmer : cible réaliste selon les attentes client + décalage horaire (clients hors Asie).
  Définir aussi (ou non) un objectif de **résolution**.

## 4. Charte graphique  *(statut : OUVERT)*

- Logo custom déjà uploadé. **Couleurs/hex et police** de marque à récupérer auprès du client pour
  finaliser le branding (cf. `docs/brand-info.md`).

## 5. Adresses email département  *(statut : OUVERT — bloquant Phase 6)*

- Aujourd'hui ADVMFR n'a qu'`advance@advmfr.com`. Le schéma 7 boîtes (`quote@`, `sales@`, `cad@`,
  `delivery@`, `accounting@`, `support@`, `contact@`) est à **créer** sur `advmfr.com`.
- À valider : noms d'adresses définitifs + qui les crée (DNS/hébergeur du client).

## 6. Politique de rétention / RGPD  *(statut : OUVERT)*

- Durée de conservation des tickets/données client (System › Data Privacy) à définir avec le client
  (et selon le droit applicable, FR/TH selon les marchés).

## 7. Monitoring — poller & destination d'alerte  *(statut : OUVERT — à brancher au cutover)*

- L'endpoint santé existe (token'd) + script `infra/zammad/healthcheck.sh`. À décider : **quel
  poller externe** (cron maison / UptimeRobot / healthchecks.io) et **vers quel canal d'alerte**
  (email, Slack, téléphone). Doit être **live à la bascule `advmfr.com`** (Phase 6).

## 8. Adresse `noreply@advmfr.com`  *(statut : OUVERT — bloquant Phase 6)*

- Les notifications système (et l'expéditeur par défaut) partent de `noreply@<fqdn>` → deviendra
  `noreply@advmfr.com`. Cette adresse doit **exister et être alignée SPF/DKIM** sinon notifications
  et brouillons partent en spam. À provisionner avec les alias département (cf. §5).

## 9. Auto-close / scheduler  *(statut : DIFFÉRÉ)*

- Pas de job d'auto-close pour l'instant (risqué : cycles devis longs, client-paced). Si adopté
  plus tard : décider **timing**, **quels états** (jamais les `open` non traités), et **exempter les
  RFQ**. Préférer que les agents passent en `pending close` (auto-clos natif) plutôt qu'un job global.