Triage des avis Shopify - avis publics bas notés en brief P0-P3

Ce que cela fait

Traite des lignes de texte d'avis de la boutique d'applications Shopify publique et produit un brief priorisé unique qu'un propriétaire de produit ou de support peut actionner : le type de problème que décrit chaque avis, à quel point il peut faire du mal, quoi faire en priorité, et où se trouvait la formulation originale.

C'est construit pour les équipes d'applications Shopify indépendantes et les agences qui gèrent leur support - le cas où les avis bas notés arrivent dispersés sur plusieurs annonces plus quelques concurrents surveiller, et le mode de défaillance est traiter tous comme également urgents.

Le barème ci-dessous n'est pas inventé ici. Il reproduit textuellement un ensemble de règles publié, donc un passage manuel et cette compétence trient la même ligne de la même manière. Voir Provenance pour la source.

Règles strictes

Ce ne sont pas des préférences de style. Casser l'une d'elles rend le résultat pire que rien.

Texte d'avis public uniquement. Ne jamais accepter, demander ou copier des tickets de support, des e-mails de commerçants, des données de commande, des coordonnées personnelles, de la télémétrie interne, ou quoi que ce soit d'autre qui ne soit pas déjà public sur une page d'annonce. Si de telles données apparaissent dans l'entrée, arrêtez, dites quelles lignes sont affectées, et demandez à les supprimer avant de continuer.
Ne jamais inventer de preuves. N'écrivez pas un avis, une note, une date, un nom d'application ou une URL source qui n'ont pas été fournis. Une ligne sans lien reçoit source: non capturée - jamais une devinez.
La sortie de mots-clés est un tri, pas un jugement. Tout ce que le barème seul produit est étiqueté premier passage - non vérification humaine. Seule une personne qui a lu l'avis et l'a vérifié contre ses propres systèmes peut relabelliser un élément vérifié humain.
Les avis sont des rapports clients, pas des défauts vérifiés. Écrivez « le critique rapporte que l'éditeur affichait un écran blanc », jamais « l'éditeur est cassé ». La distinction survit dans le brief.
Aucune affirmation de couverture. Le brief couvre exactement les lignes fournies et le dit. Ne faites aucune affirmation de couverture exhaustive d'une annonce, d'une période ou d'une application.
Aucune promesse. Aucun impact sur le chiffre d'affaires, aucun résultat, aucun effet de classement, aucun conseil juridique ou de conformité. Suggérez des actions ; ne prédisez pas les résultats.
Brouillon uniquement - ne contactez jamais personne. N'envoyez pas d'e-mail, ne postez pas de réponse de développeur, n'ouvrez pas de ticket de support, ne messagerez pas un critique, et ne publiez rien. Remettez le brouillon à l'équipe et laissez une personne décider quoi envoyer.
Les critiques sont des personnes. Référez-vous à « le critique ». Ne nommez pas, ne profilez pas ou ne spéculez pas sur eux.

1. Rassembler les lignes

Demandez un avis par ligne. Le formulaire complet conserve le lien source, dont le brief a besoin :

note | nom de l'application | date de l'avis | URL des avis publics | texte de l'avis

Une forme à trois champs plus courte est également acceptée - traitez le champ 1 comme la note quand c'est un 1-5 nu (optionnellement suivi de star ou stars), sinon comme le nom de l'application :

note | nom de l'application | texte de l'avis

Règles pour cette étape :

Les lignes commençant par # sont des commentaires. Les lignes vides sont ignorées.
Si une ligne manque une URL source, portez source: non capturée à travers le brief. Ne supprimez pas la ligne et ne fabriquez pas de lien.
Ne allez pas chercher quoi que ce soit vous-même. Cette compétence n'a besoin d'aucun accès réseau ; la personne que vous aidez colle les lignes publiques qu'elle a déjà ouvertes.
Le déclencheur pour lequel ce barème est réglé est un avis nouveau 1-3-étoiles. Les lignes plus haut notées se classent toujours correctement (un avis 5-étoiles atterrit souvent dans les demandes de fonctionnalités ou besoins-lecture-humaine), donc les gardez si elles ont été fournies, mais ne les présentez jamais comme signal bas notés.

2. Premier passage - appliquer le barème

Convertissez le texte de l'avis en minuscules et normalisez les apostrophes courbes (' en ') avant de correspondre, donc « won't load » collé correspond toujours à won't load. Correspondez également à chaque mot-clé ci-dessous avec l'apostrophe entièrement supprimée : les commerçants dactylographient régulièrement ces contractions sans apostrophe, et la version sans apostrophe doit se classer exactement comme la forme contractée.

Cinq seaux. Chaque ligne reçoit exactement un seul principal - la première dimension ci-dessous, dans cet ordre, avec n'importe quel mot-clé correspondant. Les correspondances supplémentaires sont enregistrées comme secondaires, jamais comme un deuxième élément de brief.

P0 - Risque d'incident

Le chemin d'achat, l'activation de l'application ou les données du commerçant peuvent être en jeu en ce moment. Laissé seul, cela coûte de l'argent au commerçant et les installations à l'équipe.

Action suggérée. Essayez de reproduire sur un magasin de test aujourd'hui. Si confirmé, traitez-le comme un incident : corrigez ou atténuez d'abord, puis répondez au critique avec ce qui a changé.

Mots-clés de signal. won't load, won't open, won't close, can't close, cannot close, blank screen, broken, crash, stopped working, not working, doesn't work, does not work, checkout, losing sales, lost sales, error

P1 - Friction répétée

Le produit fonctionne, mais la même lutte continue d'apparaître dans les avis ou contre un thème de support ouvert. La répétition est le signal, pas le volume d'adjectifs.

Action suggérée. Enregistrez-le contre le thème de support correspondant. Si la même plainte se répète dans les lignes, planifiez un correctif UX avant un nouveau travail de fonctionnalité.

Mots-clés de signal. confusing, unclear, hard to, difficult, complicated, clunky, slow, couldn't figure, could not figure, annoying, had to contact support, setup took, too many steps

P2 - Confusion tarifaire

Ce que le commerçant s'attend à payer et ce qui s'est produit ont divergé. Généralement un problème de copie dans l'annonce, les limites du plan ou les invites de mise à niveau - pas un problème de code.

Action suggérée. Comparez ce que le critique attendait avec la section tarifaire de l'annonce et les invites de mise à niveau in-app ; clarifiez la copie là où elles divergent.

Mots-clés de signal. pricing, price, charged, charge, billing, billed, expensive, free plan, trial, refund, hidden fee, hidden cost, paywall

P3 - Demande de fonctionnalité

Le commerçant veut quelque chose que l'application ne fait pas, ou n'a pas pu trouver. Précieux en tant qu'entrée de journal, rarement urgent en soi.

Action suggérée. Ajoutez-le au journal des demandes de fonctionnalités avec un lien vers l'avis. Si la capacité existe déjà, répondez au critique avec où la trouver.

Mots-clés de signal. wish, would be great, would love, please add, feature request, missing, if only, would like, no option to, needs an option, hope you add, add support for

Besoins lecture humaine

Aucun mot-clé n'a correspondu. Frustration vague, sarcasme, louanges mélangées ou une histoire qui a besoin de contexte.

Action suggérée. Aucun mot-clé n'a correspondu. Lisez l'avis complet vous-même et classez-le manuellement - l'heuristique ne fait aucune supposition ici.

Priorité. Le barème étiquette ce seau P2 et le trie en dernier. Traitez cette étiquette comme un placement provisoire dans la queue, pas comme un jugement de gravité - rien n'a été jugé encore.

Bris d'égalité et escalade

Le plus grave gagne. Une ligne nommant à la fois un checkout cassé et une surprise de facturation classe sous P0 avec les tarifs notés comme secondaires. Ne divisez jamais un avis dans deux éléments de brief.
La répétition escalade. Si le même thème de friction ou de tarification apparaît dans trois avis ou plus dans environ 60 jours, remontez d'un niveau et dites combien de lignes ont conduit le changement.
L'âge réduit. Un avis plus vieux qu'un an est du contexte, pas une preuve d'un problème actuel, à moins qu'une ligne récente le corrobore. Citez-le en contexte, jamais comme le titre.
Les avis concurrents ne créent jamais de P0 pour vous. Un incident d'un concurrent est une roadmap, positionnement ou entrée copie - il appartient à la section de surveillance des concurrents.
En cas de doute, choisissez besoins lecture humaine. Le seau existe pour que le barème ne blanchisse jamais l'incertitude en étiquette de priorité.

3. Passage humain - vérifiez avant de promouvoir quoi que ce soit

Le premier passage est où cette compétence cesse de pouvoir aider seule. Avant que n'importe quel élément soit présenté comme plus qu'une correspondance de mot-clé, une personne de l'équipe doit :

lire l'avis original complet à son lien source ;
pour les candidats P0, essayer de reproduire sur un magasin de développement et vérifier le suivi des erreurs et la boîte de réception du support pour les signaux correspondants de la même période ;
enregistrer le résultat comme reproduit, non reproduit ou tenté - notes jointes.

Demandez ces résultats plutôt que de les supposer. Jusqu'à ce que vous les ayez, chaque élément reste étiqueté premier passage - non vérification humaine, y compris dans la ligne de résumé. Un P0 non vérifiée est un candidat, pas un incident.

Les limites connues à indiquer clairement quand elles s'appliquent : la correspondance de mots-clés est en anglais uniquement, manque le sarcasme et le contexte, peut mal classer un avis qui mentionne « checkout » en passant, et ne voit que les lignes fournies.

4. Écrire le brief

Un document par portefeuille, sections dans l'ordre du barème, chaque élément portant un propriétaire, une action suivante et un lien source. Un élément sans propriétaire est une note, pas une entrée de brief.

# Brief d'avis bas notés - {portefeuille ou nom de l'équipe} - semaine du {AAAA-MM-JJ}

Portée : {applications surveillées} - {concurrents surveillés} - {N} lignes fournies, {plage de dates}.
Couvre uniquement les lignes fournies - pas de prétention de couverture exhaustive.
Les avis sont des rapports clients, pas des défauts vérifiés. Les éléments marqués « premier passage » sont des correspondances de mots-clés non vérifiées ; « vérifié humain » signifie qu'une personne a lu l'avis et l'a vérifié.

## P0 - Risque d'incident
- **{Application} - {signal en quelques mots}** ({note} étoiles, {date de l'avis}, [source]({URL des avis publics}))
  - Le critique rapporte : {une phrase, en ses mots si possible}
  - Statut : premier passage - non vérification humaine / vérifié humain
  - Reproduit : {oui / non / tenté - notes}
  - Action suivante : {action} - propriétaire {nom}, échéance {date}

## P1 - Friction répétée
- **{Application} - {thème}** ({note} étoiles, {date}, [source]({URL des avis publics}) ; aussi vu : {où})
  - Statut : premier passage - non vérification humaine / vérifié humain
  - Action suivante : {changement UX ou docs} - propriétaire {nom}, échéance {date}

## P2 - Confusion tarifaire
- **{Application} - {signal}** ({note} étoiles, {date}, [source]({URL des avis publics}))
  - Attendu vs actuel : {une ligne}
  - Statut : premier passage - non vérification humaine / vérifié humain
  - Action suivante : {changement copie ou invite} - propriétaire {nom}, échéance {date}

## P3 - Demandes de fonctionnalités
- **{Application} - {demande}** ({note} étoiles, {date}, [source]({URL des avis publics})) - {enregistrez-le, ou existe déjà donc répondez avec où le trouver}

## Besoins lecture humaine
- **{Application}** ({note} étoiles, {date}, [source]({URL des avis publics})) - {aucun mot-clé n'a correspondu ; ce qu'un humain devrait chercher}

## Surveillance des concurrents
- **{Concurrent} - {signal}** : {ce que cela implique pour notre roadmap, copie ou positionnement}

## Décisions cette semaine
- {une décision ou expérience, avec les lignes qui l'ont motivée}

Ouvrez la ligne de résumé avec les comptes, par ex. « Triées 8 lignes fournies : 3 risque d'incident, 2 friction répétée, 1 confusion tarifaire, 1 demande de fonctionnalité, 1 besoin lecture humaine - premier passage, non vérification humaine. »

5. Auto-vérification avant de la remettre

Refusez de livrer jusqu'à ce que chaque ligne soit vraie :

[ ] Chaque élément nomme son seau et sa priorité du barème ci-dessus, et rien d'autre.
[ ] Chaque élément porte un lien source ou un source: non capturée explicite.
[ ] Aucun texte d'avis, note, date, nom d'application ou URL n'apparaît qui n'ait pas été fourni.
[ ] Chaque élément non vérifié dit premier passage - non vérification humaine ; rien ne prétend une vérification humaine qui n'a pas eu lieu.
[ ] Les affirmations sont formulées comme des rapports (« le critique rapporte... »), pas comme des constatations sur le code.
[ ] La ligne de portée dit combien de lignes ont été fournies et ne fait aucune affirmation de couverture.
[ ] Aucune promesse sur le chiffre d'affaires, les notes, les résultats ou la conformité n'apparaît nulle part.
[ ] Aucune donnée privée n'a survécu à la sortie.
[ ] Rien n'a été envoyé, publié ou annoncé - le brief est un brouillon pour l'équipe.

Exemple travaillé

Ces huit lignes fictives exercent chaque seau. Deux d'entre elles sont délibérément 4-étoiles et 5-étoiles, pour atteindre les demandes de fonctionnalités et les seaux besoins-lecture-humaine.

1 | Example Popup App | The editor shows a blank screen and the popup won't load. We are losing sales every day.
2 | Example Popup App | The overlay can't close on mobile and it blocks the checkout button.
1 | Example Currency App | Conversion is broken at checkout and we were still billed for the month.
3 | Example Currency App | Setup took hours and the settings screen is confusing. Support was slow to reply.
3 | Example Reviews App | The widget looks fine but the template editor is confusing and hard to use on a tablet.
2 | Example Currency App | We kept getting charged after uninstalling, and the pricing page never mentioned this.
4 | Example Reviews App | Great app, but I wish it could export reviews to CSV. Please add filtering by country.
5 | Example Reviews App | Does what it promises and support replied the same day.

Premier passage sur ces lignes :

ligne 1 -> P0 risque d'incident
ligne 2 -> P0 risque d'incident
ligne 3 -> P0 risque d'incident (secondaire : confusion tarifaire)
ligne 4 -> P1 friction répétée
ligne 5 -> P1 friction répétée
ligne 6 -> P2 confusion tarifaire
ligne 7 -> P3 demande de fonctionnalité
ligne 8 -> besoins lecture humaine

Les lignes 4 et 5 ont toutes deux correspondu à confusing, donc elles sont signalées comme un thème répété - deux lignes, ce qui est un cluster à surveiller, pas encore les trois qui déclenchent l'escalade. La ligne 3 est un seul élément P0 avec les tarifs enregistrés comme secondaires, jamais deux éléments. La ligne 8 n'a rien correspondre et reste jugée. Aucune de ces lignes ne portait une URL source, donc chaque élément lirait source: non capturée jusqu'à ce que l'équipe fournisse les liens d'annonce.

Pièges

La boutique d'applications Shopify n'a pas de lien permanent stable par avis. Citez la page des avis publics de l'annonce, conservez le filtre de note si utilisé (.../reviews?ratings%5B%5D=1), et épinglez l'élément avec la date de l'avis plus les premiers mots du critique pour qu'un humain puisse le trouver à nouveau.
Préférez le formulaire à cinq champs. Il porte la date de l'avis et l'URL source dont le brief a besoin. Un analyseur à trois champs replie tout après le deuxième | dans le texte de l'avis, donc une ligne portant une date et une URL classe toujours mais les affiche à l'intérieur de l'avis cité.
checkout est le mot-clé le plus bruyant de l'ensemble. Il s'active sur « nous aimons la vente supplémentaire du checkout ». Un P0 dont la seule preuve est le mot checkout est une ligne besoins-lecture-humaine portant un badge P0 - dites-le au lieu de la promouvoir.
missing et error traversent les seaux. « manque un mode sombre » est P3 ; « la page des paramètres génère une erreur » est P0. L'ordre du seau primaire résout la collision mécaniquement ; le passage humain corrige ceux où il a mal deviné.
Les avis non-anglais ne correspondront pas du tout. Elles atterrissent besoins-lecture-humaine. C'est le résultat correct - ne traduisez pas puis ne classifiez pas comme si le mot-clé avait correspondu.
Un P0 d'un concurrent n'est pas le vôtre. Il va à surveillance des concurrents même quand la formulation est pire que quoi que ce soit sur les propres annonces de l'équipe.
Un avis, un élément. Les correspondances secondaires sont des annotations. Diviser un avis dans des sections double-compte le même commerçant et gonfle chaque compte dans la ligne de résumé.

Provenance

Les dimensions, priorités, listes de mots-clés, actions suggérées, règles de bris d'égalité et modèle de brief reproduits ci-dessus proviennent d'un guide de triage manuel publié : https://alfredtech2026.github.io/shopify-app-review-brief/guides/shopify-app-review-triage.html

Ce guide est maintenu indépendamment et n'est pas affilié à, approuvé par ou parrainé par Shopify Inc. ou un développeur d'application. Shopify est une marque commerciale de Shopify Inc.

shopify-review-triage