margin-analyzer

name	margin-analyzer
description	Utiliser quand l'utilisateur parle d'augmenter ses prix, de marges, de coûts qui grignotent le profit, ou demande « est-ce que je gagne assez ? », « je devrais facturer plus ? ». Analyse l'économie unitaire par produit/service depuis les ventes et coûts réels et montre des scénarios de prix — analyse seulement, ne recommande pas un prix. S'appuie sur le MCP foodeatup et sur ./rapido-kb/ pour les seuils maison.
source	anthropics/knowledge-work-plugins (commit 564d560c), Apache 2.0

Margin Analyzer

Nécessite le MCP foodeatup (déclaré dans le .mcp.json du plugin). Découplé de RapidoCRM : FoodEatUp porte ses propres outils CRM.

Adaptation Rapido (lire d'abord)

Ce skill vient d'un contexte US générique. Dans cette marketplace, remplacer systématiquement ses outils par les équivalents Rapido :

Outil cité dans ce skill	Équivalent à utiliser ici
QuickBooks / PayPal / Square / Stripe (finances, ventes)	FoodEatUp : finance_summary, list_orders, list_invoices, list_expenses
HubSpot (CRM, pipeline)	FoodEatUp : get_client, list_clients, list_quotes (devis restaurant) — le pipeline B2B relève du plugin rapidocrm, hors périmètre ici
Gmail (envoi d'emails)	brouillons via le plugin rapido-direction ; réponse à un avis public : reply_review (confirmée)
Google Drive / Calendar	plugin rapido-direction (coffre-documents, agenda)
Slack (notifications)	pas d'équivalent — restituer dans la conversation, ou notification via un workflow n8n (plugin rapido-n8n)
Zendesk / Shopify	pas d'équivalent direct — support : noter l'échange sur la fiche client (update_client) ; vente en ligne : carte vitrine FoodEatUp
CSV uploads	inutile si les MCP répondent — les données viennent des serveurs

Les seuils, cadences et benchmarks du skill sont des DÉFAUTS US : les seuils maison de ./rapido-kb/processus-internes.md priment (les citer).

Status: MVP draft · Owner: JJ · Version: 1.1.0 Category: Finance & Ops · Phase: V2

Quick start

When an SMB owner asks "should I raise my prices?" or "are my margins okay?", this skill:

1. Identifies what to analyze — which products/services are in scope
2. Pulls cost data — coût matière depuis les recettes FoodEatUp (get_recipe, recette-cout-marge) + dépenses directes (list_expenses)
3. Pulls revenue data — ventes réelles FoodEatUp (finance_summary, list_orders, list_invoices)
4. Computes unit economics — revenue, COGS, gross margin, margin % per item
5. Benchmarks against context — inflation, cost changes, industry norms if available
6. Builds pricing scenarios — shows what happens to revenue and margin at +5%, +10%, +15% price changes, using historical correlation where data allows
7. Presents the analysis — no price recommendation; the owner decides

The output equips the owner to make their own pricing call with real data behind it.

---

Workflow

Step 1: Pre-flight check

Établissement : confirmer l'establishment_id (le demander à la première utilisation, cf. rapido-kb/entreprise.md). Charger les seuils maison de ./rapido-kb/processus-internes.md (ils priment sur les défauts secteur).

Secteur (benchmarks) : si la catégorie d'activité n'est pas connue, la demander : « Pour situer tes marges, dans quel type d'activité es-tu ? » — puis piocher les repères dans reference/industry-benchmarks.md (défauts, à annoncer comme tels).

Serveur non connecté : si FoodEatUp/CRM ne répond pas, le dire et travailler avec les chiffres fournis par l'exploitant (dégradation propre) — ne rien inventer.

Step 2: Clarify scope

Ask the owner two questions:

1. "Which products or services do you want to analyze?"

   • All of them, or a specific subset?
   • If they say "all," confirm the connector has enough data to be meaningful before pulling everything.

2. "What metric matters most to you?"

   • Gross margin (revenue minus direct costs)?
   • Net margin (after all expenses)?
   • Revenue per unit?
   • Their answer shapes how you present the output.

Step 3: Pull cost data (FoodEatUp)

Le coût matière par plat vient des recettes : get_recipe (coût calculé depuis les ingrédients) ou le skill recette-cout-marge. Les dépenses directes viennent de list_expenses.

• Date range: Last 12 months (or full history if less is available)
• Extract: coût de revient par plat (recette), dépenses directes rattachées

Si un plat n'a pas de recette rattachée, son coût matière est inconnu — demander à l'exploitant :

• un coût par plat/prestation (matière, main-d'œuvre, coûts directs par unité)
• les évolutions de coût connues sur les 6–12 derniers mois

Si les recettes existent mais que le coût ressort à 0 (ingrédients sans prix), ne pas prendre 0 comme coût. Le signaler :

« Ce plat n'a pas de coût de revient renseigné (recette absente ou ingrédients sans prix). Pour une marge fiable, il me faut le coût par plat — matière, main-d'œuvre, coûts directs. Même une estimation fonctionne. »

Flag this limitation in the Data Quality Notes section of the final output.

Step 4: Pull revenue data (FoodEatUp)

Fetch from list_orders (ventes réelles) et finance_summary (synthèse) :

• Date range: Match the cost data window (last 12 months)
• Extract: Transaction amount, item/service name, date, quantity if available

If the MCP data is incomplete for the window, say so and offer: "Les données de vente sont partielles sur cette période — restreindre la fenêtre ou compléter par un CSV ?"

If only one data source is available, note the limitation in the output.

Step 5: Compute unit economics

For each product/service in scope, calculate:

Metric	Formula
Revenue	Sum of transaction amounts for the item
COGS	Coût de revient recette (FoodEatUp) ou fourni par l'exploitant
Gross Profit	Revenue − COGS
Gross Margin %	(Gross Profit ÷ Revenue) × 100
Units Sold	Count of transactions (if available)
Revenue per Unit	Revenue ÷ Units Sold
Cost per Unit	COGS ÷ Units Sold

Flag any item where margin is below 20% — not as a recommendation, but as a data point worth the owner's attention.

Step 6: Benchmark

Layer in context to make the numbers meaningful:

• Inflation: Note relevant cost trends if discussing input cost increases. Example: "Your input costs rose ~X% over this period while your prices held flat — that compressed margin by Y points."
• Industry benchmarks: utiliser les repères de reference/industry-benchmarks.md (normes de marge par catégorie — des défauts, à annoncer ; la KB maison prime).
• Historical comparison: If 24+ months of data is available, compare this year's margins to last year's to surface the trend direction.

Handle low-data gracefully: if fewer than 6 months of transactions exist, omit the elasticity section and note: "You need at least 6 months of pricing history to estimate how volume responds to price changes. I'll show scenario math instead."

Step 7: Pricing scenarios

Build a table for each product/service showing three price-change scenarios:

Scenario	New Price	Projected Revenue*	Gross Margin %
+5%	$X	$Y	Z%
+10%	$X	$Y	Z%
+15%	$X	$Y	Z%

How to compute projected revenue:

• If 6+ months of history: Estimate volume response using historical data. If a past price change exists, compute observed elasticity: Elasticity = % change in volume ÷ % change in price. Apply that to project volume at the new price.
• If insufficient history: Show three volume assumptions (−0%, −5%, −10%) and let the owner pick what seems realistic.

Add a note: "These are projections based on available data, not guarantees. Actual volume response depends on competition, customer sensitivity, and timing."

Step 8: Present the analysis

Structure the output as:

Structure the output with an H2 header showing the business name and date range, followed by four sections: a Unit Economics Summary table (product/service, revenue, COGS, gross margin, margin %), a Context and Benchmarking section (2-4 sentences on inflation, cost shifts, industry norms), Pricing Scenarios (scenario table per product, or top 3-5 if many), and Data Quality Notes (flag any limitations such as partial data, missing COGS, or short history).

Keep it factual. Do not say "you should raise prices" or "consider lowering your price." The owner is looking at data to make their own call.

---

Scope boundary

This skill surfaces data. It does not recommend a price.

If the owner asks "so what should I do?" — respond with: "I can show you what the data suggests, but the pricing decision is yours. Would you like me to model any additional scenarios?"

This is intentional. Pricing decisions have real business consequences and depend on context only the owner knows (competitive positioning, customer relationships, cash needs). The skill's job is to make sure they're looking at real numbers when they decide.

---

Connectors

Requis : FoodEatUp (déclaré dans le .mcp.json du plugin). Coûts = recettes/ingrédients + list_expenses ; revenus = finance_summary / list_orders / list_invoices. Aucun connecteur QuickBooks / PayPal / Square dans cet écosystème ; le CA B2B du CRM est hors périmètre (plugin rapidocrm).

---

Reference files

• reference/gotchas.md — common pitfalls (data gaps, elasticity traps, margin math errors)
• reference/industry-benchmarks.md — gross margin ranges by SMB category
• reference/csv-schema.md — expected columns when the owner uploads a CSV
• reference/examples/ — worked scenarios (retail, services, product-based)