Une décision, du début à la fin.La mesure peut dire non.
Un playbook suit une décision d'exploitation à travers marql : le signal, le calcul dessous, les actions possibles, et la période de contrôle qui décide si l'effet compte. De vrais écrans produit, des chiffres issus du compte de démonstration.
Ce que suit chaque playbook
Quatre étapes, et deux d'entre elles peuvent finir sans chiffre.
Les mêmes quatre étapes dans chaque playbook, dans cet ordre. Deux portent un verrou — un point où la sortie honnête est un trou plutôt qu'un chiffre, et où marql est fait pour montrer le trou.
Le trouver avant la clôture de la période
Un passage quotidien sur les flux bruts, pas un rapport que quelqu'un pense à ouvrir. Les écarts sont classés par ce qu'ils valent en argent : la liste commence là où est l'argent, pas là où une alerte s'est déclenchée.
Séparer la cause du symptôme
Du stock dormant et un produit qui se vend avec trop de couverture sont identiques dans un état de stock et demandent des actions opposées. Le diagnostic lit l'écoulement, la saison et la disponibilité dans les autres points de vente avant de dire lequel des deux c'est.
Pas de prix de revient dans le flux — le playbook compte les unités en excès et laisse la colonne argent vide plutôt que de l'estimer
Mettre une action en face d'un nom et d'une date
Plusieurs options, parce que le bon geste dépend de choses qu'un modèle ignore : suspendre le réapprovisionnement, déplacer du stock entre points de vente, baisser le prix, ou changer le seuil. Chacune porte un responsable, une échéance et une date de revue.
La mesurer face à une référence
La période de référence et la fenêtre de mesure sont fixées à la confirmation de l'action, pas choisies après coup. Rien n'est compté comme un effet avant la fermeture de la fenêtre.
La fenêtre ne peut pas séparer l'action d'un facteur externe — le registre enregistre « sans effet » ou « pas assez de données », et aucune économie n'est revendiquée
Ce qu'un playbook doit énoncer sur la page
Six choses, et les deux dernières sont celles qui manquent d'habitude.
L'exemple travaillé d'un éditeur est facile à écrire et facile à ne pas croire. Ces six éléments sont ce qui le rend vérifiable, donc chaque playbook de la bibliothèque les porte tous les six.
La question, avec vos mots
La question avec laquelle un opérateur arrive vraiment, avant d'avoir été traduite dans le vocabulaire du produit.
Imprimée en haut du playbook, avec les cinq ou six relances en dessous, dans l'ordre où elles arrivent.
Le jeu de données minimal
Quels flux doivent être connectés pour que la décision soit seulement possible, et lesquels ne font qu'améliorer la précision.
Trois niveaux, nommés : requis, requis avant tout chiffre en argent, et améliore la précision. Aucun playbook ne laisse croire qu'il fonctionne avec moins que ce dont il a besoin.
Comment le chiffre est calculé
Si le chiffre est l'avis d'un modèle ou une arithmétique que vous pourriez refaire dans un tableur.
Les quantités sont déterministes — stock disponible, demande moyenne quotidienne, délai d'approvisionnement, stock tampon cible. L'IA explique le raisonnement ; elle ne produit pas le chiffre.
Plus d'une action
Une recommandation unique est un signal : cela veut dire que l'outil n'a modélisé que le symptôme, pas l'arbitrage.
Chaque playbook se termine sur un jeu d'options avec leurs conditions, et le choix reste à la personne qui en assume la conséquence.
Où s'arrête le potentiel et où commence la preuve
La seule section que la plupart des supports d'éditeurs omettent, parce que le chiffre a meilleure allure sans elle.
Un bloc à part entière, dans le même corps que le reste de la page : ce que le chiffre-titre est, et ce qu'il n'est pas. C'est un potentiel sur des données de démonstration, pas une économie encaissée par quiconque, et pas notre ROI.
De vrais écrans, étiquetés données de démonstration
Si l'interface des images est le produit livré ou l'illustration d'un designer.
De vrais écrans, et le cadre autour de chacun indique quel compte et que les chiffres sont synthétiques. Les données d'aucun client n'apparaissent dans un playbook.
Qui a écrit ceci
Ce que la bibliothèque ne fait pas encore.
Ce sont nos propres exemples travaillés sur nos propres données de démonstration. Voici exactement ce que cela vaut et où cela s'arrête.
- Un playbook est publié. Il n'y a pas de liste de ceux en cours d'écriture, parce qu'un sommaire de liens vers des pages qui n'existent pas est une promesse sans date.
- Aucun résultat client n'apparaît dans un playbook. marql n'a pas de réseau signé dont il pourrait publier les chiffres, donc chaque chiffre vient du compte de démonstration et le dit sur l'écran où il apparaît.
- Aucun playbook ne garantit un pourcentage. Deux des plateformes de cette catégorie vendent exactement cela — un plancher sur ce qu'un audit trouvera — et c'est une offre défendable avec un carnet de missions derrière. Nous n'en avons pas, donc nous ne chiffrons pas le risque.
- Chaque chiffre est un potentiel, calculé sur les données de démonstration. Un potentiel ne devient un effet qu'après une action, une période de référence et une fenêtre de contrôle, et le registre a le droit de conclure que ce n'en fut pas un.
- Aucun playbook n'indique combien de temps tout cela prend sur vos données. Le produit ne s'engage pas sur une durée, donc rien ici n'en laisse entendre une.
- Les textes sont publiés en anglais, roumain, bulgare, français et espagnol ; les écrans produit qui s'y trouvent sont en anglais sur tous les marchés, parce que le compte de démonstration tourne en anglais et que réenregistrer cinq écrans par langue ne prouverait rien de plus.
Questions fréquentes
À propos des playbooks
Non, et la différence compte. Une étude de cas est le résultat d'un client, raconté avec son accord et ses chiffres. Un playbook est une décision travaillée de bout en bout sur notre compte de démonstration : les mêmes écrans qu'un client verrait, avec des chiffres que nous avons générés. Il n'y a de client dans aucun d'eux, et c'est pourquoi rien sur ces pages n'est attribué à quiconque.
Les écrans sont le produit livré. Les chiffres qu'ils contiennent viennent du compte de démonstration et sont étiquetés comme synthétiques dans le cadre autour de chaque image. Ce qui est réel et vérifiable, c'est la méthode — ce qui déclenche le signal, quelles entrées le calcul demande, comment la quantité est calculée, et ce que fait le registre quand la fenêtre de contrôle n'est pas concluante.
Anglais, roumain, bulgare, français et espagnol — les marchés que le site sert. Les captures produit sont en anglais partout : le compte de démonstration tourne en anglais, et ce que ces écrans doivent prouver, c'est l'enchaînement de la décision, pas la langue de l'interface. Le produit lui-même s'utilise dans la langue locale.
C'est exactement ce qu'est la séance de travail : vos données de ventes et de stock, les mêmes quatre étapes, et les écarts qui sont réellement dans votre réseau plutôt que dans le compte de démonstration. Cela ne demande aucune préparation de votre côté, hormis un accès en lecture aux systèmes qui portent les ventes et les coûts.
D'où viennent les écrans
Decision Inbox
Là où le signal arrive, classé par ce qu'il vaut plutôt que par l'heure où il s'est déclenché.
Copilot
Là où la cause est séparée du symptôme, et où les options sont mises côte à côte.
Impact Ledger
Là où l'effet est mesuré, et où il est enregistré comme non prouvé quand il ne peut pas l'être.
Comment marql s'assemble
La connexion, le passage quotidien et le brief, pour un lecteur arrivé d'abord sur un playbook.
Parlons-en
Parlez-nous de votre activité. Nous vous rappelons.
Dites-nous en deux mots ce que vous gérez et d'où viennent vos données. Nous adaptons la démonstration, puis vous choisissez l'horaire qui vous arrange.