| 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:
- Identifies what to analyze — which products/services are in scope
- Pulls cost data — coût matière depuis les recettes FoodEatUp (
get_recipe,
recette-cout-marge) + dépenses directes (list_expenses)
- Pulls revenue data — ventes réelles FoodEatUp (
finance_summary,
list_orders, list_invoices)
- Computes unit economics — revenue, COGS, gross margin, margin % per item
- Benchmarks against context — inflation, cost changes, industry norms if available
- Builds pricing scenarios — shows what happens to revenue and margin at +5%, +10%, +15% price changes, using historical correlation where data allows
- 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:
-
"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.
-
"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 categoryreference/csv-schema.md — expected columns when the owner uploads a CSVreference/examples/ — worked scenarios (retail, services, product-based)
