E-commerce
1 juillet 2026
« J'étais 47e sur la liste, pourquoi quelqu'un d'autre a reçu le sien avant moi ? » « La précommande est pleine mais le site accepte encore mon paiement. » « Quand exactement part mon colis si c'est une précommande limitée à 500 unités ? » Trois messages où une précommande capée mal expliquée transforme l'excitation lancement en tickets SAV et chargebacks.
Un chatbot IA précommandes limitées e-commerce ne remplace pas la policy précommande agents (#187). Il lit cap inventory, queue position, priorité VIP et ship_date grounded, explique file d'attente et statut order, et handoff si retard ou annulation.
Ce guide #405 couvre intents bot_pre_lim_*, flow WAIT-BOT et KPI lim_pre. Distinct du SAV précommande (#187) (agents, compensation) et du bot édition limitée drop (#222) : ici, cas d'usage IA file d'attente, priorité client et transparence précommande capée.
Sommaire
Pourquoi les précommandes limitées surchargent-elles le chat ?
Une précommande limitée vend un produit futur avec quantité plafonnée (500 unités, 2 000 slots) et date d'expédition estimée. Le client paie aujourd'hui, attend des semaines, et compare sa position aux autres.
Cinq tensions client typiques
Queue opaque : « suis-je encore inscrit ? » sans numéro visible
Priorité VIP floue : early access sans règle claire
Cap dépassé : paiement accepté alors que slots épuisés
Ship date glissante : fourchette initiale non tenue (#187)
Panier mixte : 1 ligne préco limitée bloque ship reste (#357)
Shopify rappelle qu'une précommande exige transparence date expédition et notification proactive retard (Shopify, précommandes 2026). Alhena estime que 62 % des consommateurs achètent plus volontiers un produit édition limitée, mais que l'absence de réponse file d'attente multiplie frustration post-drop (Alhena, support drops 2026).
Angle #405 vs contenus voisins
SAV précommande #187 : agents, annulation, compensation. Le #405 = bot exécute queue et transparence 24/7.
Bot drop LE #222 : sold out instant, stock live drop. Le #405 = précommande capée sur semaines, pas drop J+0.
Com Shopify #comm : PDP, emails marketing. Le #405 = conversation chat post-achat et pré-achat queue.
Rupture planifiée #404 : fin série sans réassort. Le #405 = réassort daté avec cap slots.
Bot prep #396 : délai entrepôt unfulfilled. Le #405 = preorder tag + queue avant production.
Exemple DTC
Marque sneakers, préco limitée 800 paires, ship 8 sem. Sans WAIT-BOT : 214 tickets launch week, queue CSAT 2,9/5. Après bot : lim_pre_bot_resolution 78 %, queue_position_ticket_rate -61 %, chargeback 0.
Préco limitée vs préco ouverte
Ouverte : pas de cap, ship date seule contrainte (#187). Limitée : cap slots + queue + priorité. Deux configs bot distinctes.
En quoi le bot préco limitée diffère-t-il du drop #222 ?
Trois modèles lancement produit, trois logiques bot.
Matrice modèle → bot playbook
#405 WAIT-BOT : préco capée, queue semaines, ship_date
#222 drop LE : stock live J+0, sold out minutes
#187 agents PRE : litiges retard, refund, compensation
Quatre attributs préco limitée
preorder_cap : qty max slots (ex. 800)
preorder_ship_window : fourchette grounded prod (ex. sem 12-14)
queue_enabled : waitlist si cap atteint avant close
priority_tiers : VIP, newsletter, public (ordre documenté)
Cycle conversation bot
Pré-achat : cap restant, éligibilité queue, priorité tier. Post-achat : position queue, ship window, statut production. Retard : reroute #187 handoff, pas promesse bot seul.
Promesse #405
Policy PRE-LIM bot, 12 intents bot_pre_lim_*, flow WAIT-BOT, guardrails cap, KPI lim_pre_*.
Quels intents bot_pre_lim_* configurer ?
Douze intents bot précommande limitée couvrent queue et transparence.
Douze intents bot_pre_lim
bot_pre_lim_cap_remaining : « reste-t-il des places ? » pré-achat
bot_pre_lim_join_waitlist : cap atteint, inscription queue
bot_pre_lim_queue_position : « où suis-je dans la file ? »
bot_pre_lim_priority_check : éligibilité VIP / early access
bot_pre_lim_ship_date : fourchette livraison grounded order
bot_pre_lim_order_status : unfulfilled preorder, phase production
bot_pre_lim_slot_confirmed : slot validé post-paiement cap OK
bot_pre_lim_slot_waitlisted : payé mais queue, pas slot garanti
bot_pre_lim_cancel_policy : annulation préco limitée (#187 reroute)
bot_pre_lim_mixed_cart : panier préco + stock standard
bot_pre_lim_delay_update : ship window glissante, notification
bot_pre_lim_oversell_detect : cap dépassé, handoff urgent agent
Tags helpdesk handoff
lim_pre, lim_pre_queue, lim_pre_vip, lim_pre_oversell, lim_pre_delay, lim_pre_bot_resolved. Distinct preorder_general, drop_le.
Router upstream
Si order fulfilled → reroute WISMO #184. Si unfulfilled sans tag preorder → reroute PREP-BOT #396. Si cancel/refund demande → handoff #187.
Comment appliquer le flow WAIT-BOT en huit étapes ?
Le flow WAIT-BOT structure réponse préco limitée grounded data.
Huit étapes WB-1 à WB-8
WB-1 Accueil : « Assistant IA précommande [SKU]. Je vérifie votre statut. »
WB-2 Collecter : order_id ou email + OTP logged-out
WB-3 Lookup : order tags preorder, line_item cap SKU, inventory sold
WB-4 Classifier : intent bot_pre_lim_* section 3
WB-5 Queue calc : position, tier priority, slots_remaining
WB-6 Expliquer : template grounded ship_window + queue status
WB-7 Handoff si besoin : oversell, delay > 14 j, cancel refund
WB-8 Clore : lien portail statut, email update opt-in
WB-5 algorithme queue position
Position = rank(order.created_at) among orders tag lim_pre_confirmed same SKU, adjusted priority_tier (VIP -N positions). Afficher fourchette « entre position 120 et 140 » si batch allocation, pas numéro exact si policy privacy.
WB-6 template slot_confirmed
« Votre slot #[rank]/[cap] est confirmé. Expédition estimée [ship_window]. Statut actuel : [production_phase]. Notification email si changement. »
WB-6 template waitlisted
« Cap atteint. Vous êtes en file position ~[rank]. Si slot se libère (annulation), notification sous 24 h. Remboursement possible (#187). »
WB-7 handoff champs ticket
order_id, sku, queue_position, priority_tier, cap_sold, ship_window, verbatim, bot_intent.
Quelle policy PRE-LIM bot documenter ?
La policy bot préco limitée PRE-LIM encadre promesses et guardrails IA.
Huit règles PRE-LIM bot
Cap source : inventory cap Shopify metafield ou app preorder, read-only bot
Queue transparente : position ou fourchette affichée si slot_confirmed ou waitlisted
Priority tiers : VIP > newsletter > public, documenté /pages/preorder
Ship window : fourchette prod grounded, jamais date ferme bot sans metafield
No oversell promise : bot ne confirme slot si cap_sold >= cap_max
Delay reroute : glissement > 14 j → handoff #187 compensation
Cancel collect : bot collecte raison, handoff agent exécute refund
Mixed cart : expliquer ship split ou hold complet selon policy #357
Publication /pages/preorder-limited
Cap total, tiers priorité, ship window, politique annulation, FAQ queue. Bot cite URL en WB-6.
Sync comm Shopify #comm
Messages PDP et checkout alignés bot templates. Pas « livraison 48 h » sur SKU preorder limitée.
Revue hebdo launch month
Ops update production_phase metafield. Bot lit latest, pas cache stale.
Quels guardrails empêchent le bot de sur-promettre ?
La matrice bot préco limitée autorisé vs interdit protège marque et cap.
Actions autorisées bot
Lookup cap_remaining live inventory + orders count
Calcul queue position grounded created_at + tier
Expliquer ship_window metafield production
Inscrire waitlist email si cap full (Klaviyo #48 sync)
Confirmer slot_confirmed si order dans cap
Expliquer priority tier eligibility (logged-in tag check)
Créer ticket handoff oversell/delay/cancel
Reroute WISMO #184 si fulfilled, PREP #396 si standard unfulfilled
Actions interdites bot
Confirmer slot si cap dépassé (oversell)
Promettre ship date ferme non grounded
Accorder priorité VIP non documentée
Exécuter refund ou cancel sans handoff agent
Compensation geste commercial (handoff #187)
Modifier queue position manuellement
Hard block oversell
Si count(confirmed_orders) > cap_max : bot_pre_lim_oversell_detect → alert Slack + handoff P0. Template : « Vérification équipe en cours sous 4 h. »
Production phase labels
Metafields : tooling, production, QC, inbound_warehouse, ready_to_ship. Bot traduit en langage client sans jargon usine.
Comment intégrer Shopify et apps précommande ?
L'intégration bot préco limitée Shopify fournit données cap et queue sans hallucination.
Champs read-only bot
product metafield preorder_cap : max slots
product metafield ship_window_start/end : fourchette ISO
order tag preorder + lim_pre_confirmed : slot validé
order tag lim_pre_waitlisted : queue sans slot
customer tag vip_tier : priority eligibility
inventory quantity + continue_selling : cap enforcement
production_phase metafield : statut usine
Shopify Admin API orders + product metafields (Shopify, Order API 2026).
Apps preorder compatibles
Pre-Order Manager, PreProduct, Timesact : webhook cap_reached → bot trigger waitlist flow. Tag auto lim_pre_* on order create.
Klaviyo waitlist sync
bot_pre_lim_join_waitlist → list Klaviyo #48. Slot libéré → flow conversion auto before agent contact.
Webhook oversell guard
Order create if count > cap : flag oversell, disable bot slot_confirmed template, route bot_pre_lim_oversell_detect immédiat.
Comment gérer priorité VIP et early access ?
La matrice priorité préco limitée PRI-TIER évite accusations favoritisme.
Trois tiers documentés
Tier 1 VIP : LTV > 500 € ou abonné box, accès T-24 h, queue boost -50 positions
Tier 2 newsletter : inscrit 30 j+, accès T-12 h, boost -20 positions
Tier 3 public : ouverture générale, position chronologique pure
Bot priority_check flow
WB-3 lookup customer tags → WB-5 apply boost → WB-6 explain tier + effective position. Si non éligible VIP : expliquer critères, pas négociation bot.
Transparence client
« Votre tier : Newsletter (T-12 h). Position effective ~85/800 après boost early access. » Lien /pages/preorder-limited section PRI-TIER.
Distinction drop #222
Drop LE = stock live minutes. PRI-TIER ici = préco window jours/semaines. Pas virtual queue checkout Shopify Plus seul.
Anti-favoritisme
Règles PRI-TIER publiées avant launch. Bot cite policy, jamais invente exception.
Quels KPI lim_pre bot mesurer ?
Les KPI bot précommande limitée pilotent automation et handoff.
Huit métriques clés
lim_pre_bot_resolution_rate : résolu sans handoff / sessions lim_pre
queue_position_ticket_rate : tickets « où suis-je » / total preco orders
waitlist_convert_rate : waitlisted → slot_confirmed / waitlisted total
lim_pre_oversell_incidents : count cap dépassé (cible 0)
lim_pre_handoff_rate : escalades #187 / sessions
lim_pre_false_promise : promesse ship ferme incorrecte audit (cible 0)
lim_pre_bot_csat : satisfaction sessions tag lim_pre
priority_check_accuracy : tier bot = tier policy / checks
Benchmark DTC launch
lim_pre_bot_resolution 70-80 %, queue_position_ticket -50 % vs sans bot, oversell 0, handoff < 22 %, bot_csat > 4,2/5.
Dashboard launch week
Sessions par intent, cap_remaining hourly, waitlist growth, oversell alerts, handoff reasons breakdown.
Post-launch mois 1-2
delay_update intent trend, ship_window adherence, corrélation production_phase updates vs tickets.
Quels anti-patterns éviter sur bot préco limitée ?
Dix anti-patterns bot précommande capée à bannir.
1. Bot confirme slot sans lookup cap
Hallucination LLM. WB-3 inventory count obligatoire.
2. Position queue inventée
Client vérifie avec agent, contradiction. Algorithme WB-5 déterministe.
3. Mélanger drop #222 et préco #405
Intents drop sold_out sur SKU preorder capée = confusion.
4. Ship date marketing ≠ metafield prod
PDP « mars » vs prod « avril ». Bot lit metafield prod only.
5. Refund bot auto
Cancel policy #187 = agent ou workflow approuvé. Collect only.
6. VIP boost non documenté
Accusation triche queue. PRI-TIER public avant launch.
7. Cache cap stale launch day
Bot dit « 200 places » alors que 0. Refresh live WB-3.
8. Ignorer waitlisted orders
Client payé sans slot : template waitlisted, pas slot_confirmed.
9. Pas handoff oversell
Cap +1 = crise. Alert P0 immédiat.
10. Production phase jamais updated
Bot répète « tooling » 8 semaines. Ops update hebdo.
11. Mixed cart silence
Client croit tout ship J+3. bot_pre_lim_mixed_cart obligatoire checkout post.
Comment Qstomy gère les précommandes limitées ?
Qstomy sur Shopify : WAIT-BOT avec cap lookup, queue position calc, PRI-TIER boost, production_phase templates, oversell hard block, handoff #187 pré-rempli.
Capacités lim_pre Qstomy
lim_pre_intent_detect : 12 intents section 3
lim_pre_cap_live : inventory + order count WB-3
lim_pre_queue_calc : position + PRI-TIER boost WB-5
lim_pre_ship_grounded : metafield window only
lim_pre_oversell_block : alert + handoff P0
lim_pre_waitlist_klaviyo : sync #48 on join
Complément #187 et #222
Agents #187 exécutent compensation et litiges. Bot #222 couvre drops instant. WAIT-BOT #405 = préco capée semaines. Pipeline : bot transparence → agent exception.
Scénario DTC chiffré
Sneakers 800 cap, 6 sem ship window, VIP tier 120 clients.
Après WAIT-BOT Qstomy : lim_pre_bot_resolution 79 %, queue_position_ticket_rate -63 %, waitlist_convert_rate 34 %, oversell 0, lim_pre_bot_csat 4,3/5.
Explorez support client et demander une démo.
Quelle checklist pour déployer WAIT-BOT ?
Checklist WAIT-BOT (12 étapes)
Documenter cap, ship_window, PRI-TIER policy PRE-LIM
Configurer metafields preorder_cap, ship_window, production_phase
Publier /pages/preorder-limited FAQ queue
Aligner comm PDP/checkout #comm avec bot templates
Configurer 12 intents bot_pre_lim_* section 3
Implémenter flow WB-1 à WB-8 + queue algo WB-5
Activer guardrails oversell hard block + no refund auto
Brancher Klaviyo waitlist #48 + slot libéré flow
Setup webhook oversell alert Slack P0
Intégrer handoff #187 champs ticket WB-7
Tests staging : cap full, waitlist, VIP boost, oversell, mixed cart
Dashboard KPI lim_pre launch week + audit transcripts
En bref
#405 = bot préco capée, pas drop LE (#222) ni SAV agents (#187)
WAIT-BOT : cap → queue → ship_window → handoff
PRI-TIER : priorité documentée, boost déterministe
Guardrails : no oversell, no refund auto, ship grounded
KPI queue_position_ticket_rate : mesure succès transparence
FAQ
Différence avec #222 drop ?
#222 = stock live minutes, sold out instant. #405 = préco capée sur semaines avec queue.
Différence avec #187 agents ?
#187 = litiges, compensation, cancel exécution. #405 = bot transparence queue et statut 24/7.
Afficher position exacte ou fourchette ?
Fourchette recommandée si batch allocation. Exact si FIFO strict documenté.
Cap atteint mid-checkout ?
App preorder block + bot waitlist. Webhook oversell si edge race condition.
Relation #404 planned OOS ?
#404 = fin série sans réassort. #405 = réassort daté avec slots limités.
Aller plus loin
Cette semaine : documentez cap et PRI-TIER, configurez metafields Shopify, activez intents bot_pre_lim_* et testez oversell guard en staging.
Partagez ce guide #405 avec ops et e-com : une précommande limitée réussie se joue autant dans la file d'attente transparente que dans le produit.
Bot peut-il convertir waitlist en commande ?
Non directement. Klaviyo flow #48 envoie lien checkout slot libéré. Bot confirme statut post-achat.
Enzo
1 juillet 2026
