Quand un RFP arrive vendredi avec une échéance lundi, /sales-engineer score la couverture et vous donne une décision bid/no-bid en 30 minutes. — Claude Skill
Une compétence Claude pour Claude Code par Alireza Rezvani — exécuter /sales-engineer dans Claude·Mis à jour le 8 juin 2026·v1.0.0
Scorez les RFPs, construisez des matrices concurrentielles et planifiez les POCs en avant-vente.
- Analyseur RFP avec scoring de couverture (Complet / Partiel / Planifié / Écart) et recommandation bid/no-bid : Bid (>70 % + ≤3 écarts must-have), Conditional, No-Bid
- Constructeur de matrice concurrentielle : scoring feature par feature (Full=3, Partial=2, Limited=1, None=0), scores pondérés, différenciateurs, vulnérabilités, win themes
- Planificateur POC avec timeline en 5 semaines, critères de succès, scorecard d'évaluation (>60 % pour convertir) et cadre go/no-go
- Workflow avant-vente en 5 phases : Discovery → Solution Design → Demo → POC → Proposal & conclusion
- Templates : proposition technique, script de démo, scorecard POC, données RFP d'exemple
Pour qui
Scorez la couverture RFP et obtenez une recommandation bid/no-bid avant d'engager 40 heures dans une réponse
Voir les compétences de ce rôleConstruisez matrice concurrentielle et script de démo pour les opportunités enterprise avec plusieurs concurrents
Voir les compétences de ce rôleStandardisez la planification POC dans l'équipe avec critères de succès et scorecards go/no-go
Voir les compétences de ce rôleCe qu'il fait
Un RFP de 50 pages vient d'arriver et l'équipe SE débat bid vs no-bid. /sales-engineer score la couverture des exigences (Must-Have ×3, Should-Have ×2, Nice-to-Have ×1), signale les écarts et donne un avis bid/no-bid en 30 minutes — pas 8 heures de débat.
L'AE demande une fiche concurrentielle concurrentielle avant la démo. /sales-engineer construit une matrice feature par feature avec scores pondérés, identifie vos différenciateurs (là où vous êtes Full et eux Partial/None) et expose les vulnérabilités à traiter.
Procurement exige un POC structuré. /sales-engineer planifie Setup (semaine 1), Core Testing (semaines 2-3), Advanced Testing (semaine 4) et Evaluation (semaine 5) avec critères de succès hebdomadaires et scorecard go/no-go finale.
Le VP demande pourquoi vous avez perdu Acme. /sales-engineer revoit phase par phase : couverture RFP, positionnement concurrentiel, exécution démo ou scoring POC — et quelle phase investir le trimestre prochain.
Fonctionnement
Phase 1 — Discovery : lancez rfp_response_analyzer sur le JSON d'exigences, obtenez score de couverture et nombre d'écarts must-have.
Phase 2 — Solution Design : lancez competitive_matrix_builder, obtenez différenciateurs par priorité et vulnérabilités à traiter.
Phase 3 — Demo : construisez le script depuis demo_script_template, checkpoint de validation face aux exigences must-have.
Phase 4 — POC : lancez poc_planner avec timeline par phase, critères de succès et jalons hebdomadaires.
Phase 5 — conclusion : proposition technique depuis template_proposal, analyse win/loss après décision.
Exemple
Acme Inc — RFP pour Customer Data Platform 84 exigences : 22 Must-Have, 38 Should-Have, 24 Nice-to-Have Deadline : lundi 17h (3 jours) 3 concurrents connus : Segment, mParticle, RudderStack
Couverture globale : 73 % (seuil Bid : >70 %) Must-Have : 18 Complet / 2 Partiel / 1 Planifié / 1 Écart (95 % couvert) Should-Have : 24 Complet / 9 Partiel / 5 Écart (87 % couvert) Nice-to-Have : 11 Complet / 8 Partiel / 5 Écart (79 % couvert)
✅ Couverture 73 % (> seuil 70 %) ✅ Écarts Must-Have : 1 (≤ seuil 3) Le seul écart Must-Have est le rate limiting API à 10K/sec — nous supportons 5K/sec. Bid conditionnel possible si nous nous engageons à une livraison roadmap en T3.
ÉCART — Req #14 : rate limiting API 10K/sec → proposer engagement roadmap T3 PARTIEL — Req #28 : SOC 2 Type II → nous avons Type I, obtenir attestation avant deadline PARTIEL — Req #41 : règles de rétention personnalisées → workaround documenté via webhooks
Différenciateur (Full vs concurrent Partial/None) : ✓ Résolution d'identité temps réel (nous Full, Segment Partial) ✓ Résidence des données UE (nous Full, mParticle None) ✓ Sync warehouse natif (nous Full, RudderStack Partial) Vulnérabilité : throughput à 5K/sec (Segment Full à 50K/sec)
→ Jour 1 : rédiger les sections de réponse 1-4 avec technical_proposal_template → Jour 2 : préparation démo — focus sur identity resolution + warehouse sync (différenciateurs) → Jour 3 : revue finale avec engineering sur l'engagement rate limiting, soumission avant 17h
Métriques améliorées
Compatible avec
Lit les documents RFP et stocke les propositions techniques générées
Récupère contexte du opportunité, étape d'opportunité et mentions de concurrents pour le scoring RFP
Source CRM alternative pour les données d'opportunité et de opportunité
Stocke propositions techniques, scripts de démo et plans POC dans Notion
Envie d'utiliser Skill Sales Engineer ?
Choisissez comment commencer.
Installez et exécutez cette compétence localement sur votre ordinateur.
Ouvrez un terminal sur votre ordinateur et collez cette commande :
Cela télécharge la compétence avec tous ses fichiers sur votre ordinateur :
Ajoutez -g à la fin pour le rendre disponible dans tous vos projets.
Démarrez Claude Code, puis tapez la commande :
Skill Sales Engineer
Workflow en 5 phases
Phase 1 : Découverte & recherche
Objectif : comprendre les exigences client, l'environnement technique et les moteurs business.
Checklist :
- Conduire des appels de découverte technique avec les parties prenantes
- Cartographier l'architecture actuelle du client et ses points de douleur
- Identifier les exigences et contraintes d'intégration
- Documenter les exigences de sécurité et de conformité
- Évaluer le paysage concurrentiel pour cette opportunité
Outils : lancer rfp_response_analyzer.py pour scorer l'alignement initial avec les exigences.
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json --format json > phase1_rfp_results.json
Sortie : document de découverte technique, cartographie des exigences, évaluation initiale de couverture.
Point de validation : le score de couverture doit être >50% et les écarts must-have ≤3 avant de passer à la Phase 2. Vérifier avec :
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json --format json | python -c "import sys,json; r=json.load(sys.stdin); print('PROCEED' if r['coverage_score']>50 and r['must_have_gaps']<=3 else 'REVIEW')"
Phase 2 : Conception de solution
Objectif : concevoir une architecture de solution qui répond aux exigences client.
Checklist :
- Mapper les capacités produit aux exigences client
- Concevoir l'architecture d'intégration
- Identifier les besoins de personnalisation et l'effort de développement
- Construire la stratégie de différenciation concurrentielle
- Créer les schémas d'architecture de solution
Outils : lancer competitive_matrix_builder.py avec les données de Phase 1 pour identifier différenciateurs et vulnérabilités.
python scripts/competitive_matrix_builder.py competitive_data.json --format json > phase2_competitive.json
python -c "import json; d=json.load(open('phase2_competitive.json')); print('Differentiators:', d['differentiators']); print('Vulnerabilities:', d['vulnerabilities'])"
Sortie : architecture de solution, positionnement concurrentiel, stratégie de différenciation technique.
Point de validation : confirmer qu'il existe au moins un différenciateur fort par priorité client avant de passer à la Phase 3. Si aucun différenciateur n'est trouvé, escalader à l'équipe Produit (voir Points d'intégration).
Phase 3 : Préparation & livraison de démo
Objectif : livrer des démonstrations techniques convaincantes, adaptées aux priorités des parties prenantes.
Checklist :
- Construire un environnement de démo correspondant au cas d'usage du client
- Créer un script de démo avec talking points par rôle de partie prenante
- Préparer les réponses de traitement des objections
- Répéter les scénarios d'échec et chemins de récupération
- Collecter les retours et ajuster l'approche
Templates : utiliser assets/demo_script_template.md pour une préparation de démo structurée.
Sortie : démo personnalisée, talking points par partie prenante, capture des retours.
Point de validation : le script de démo doit couvrir chaque exigence must-have signalée dans phase1_rfp_results.json avant livraison. Croiser avec :
python -c "import json; rfp=json.load(open('phase1_rfp_results.json')); [print('UNCOVERED:', r) for r in rfp['must_have_requirements'] if r['coverage']=='Gap']"
Phase 4 : POC & évaluation
Objectif : exécuter un proof-of-concept structuré qui valide la solution.
Checklist :
- Définir le périmètre du POC, les critères de succès et le calendrier
- Allouer les ressources et configurer l'environnement
- Exécuter les tests par phases (core, avancé, cas limites)
- Suivre la progression par rapport aux critères de succès
- Générer une scorecard d'évaluation
Outils : lancer poc_planner.py pour générer le plan POC complet.
python scripts/poc_planner.py poc_data.json --format json > phase4_poc_plan.json
python -c "import json; p=json.load(open('phase4_poc_plan.json')); print('Go/No-Go:', p['recommendation'])"
Templates : utiliser assets/poc_scorecard_template.md pour le suivi de l'évaluation.
Sortie : plan POC, scorecard d'évaluation, recommandation go/no-go.
Point de validation : la conversion du POC nécessite un score de scorecard >60% sur toutes les dimensions d'évaluation (fonctionnalité, performance, intégration, utilisabilité, support). Si le score est <60%, documenter les écarts et revenir à la Phase 2 pour reconcevoir la solution.
Phase 5 : Proposition & conclusion
Objectif : livrer une proposition technique qui soutient la conclusion commerciale.
Checklist :
- Compiler les résultats POC et les métriques de succès
- Créer la proposition technique avec le plan d'implémentation
- Traiter les objections restantes avec des preuves
- Soutenir les discussions de pricing et packaging
- Conduire l'analyse win/loss après décision
Templates : utiliser assets/technical_proposal_template.md pour le document de proposition.
Sortie : proposition technique, calendrier d'implémentation, plan de mitigation des risques.
Outils d'automatisation Python
1. RFP Response Analyzer
Script : scripts/rfp_response_analyzer.py
Objectif : parser les exigences RFP/RFI, scorer la couverture, identifier les écarts et générer des recommandations bid/no-bid.
Catégories de couverture : Full (100%), Partial (50%), Planned (25%), Gap (0%).
Pondération de priorité : Must-Have 3×, Should-Have 2×, Nice-to-Have 1×.
Logique Bid/No-Bid :
- Bid : couverture >70% ET écarts must-have ≤3
- Conditional Bid : couverture 50–70% OU écarts must-have 2–3
- No-Bid : couverture <50% OU écarts must-have >3
Utilisation :
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json # human-readable
python scripts/rfp_response_analyzer.py assets/sample_rfp_data.json --format json # JSON output
python scripts/rfp_response_analyzer.py --help
Format d'entrée : voir assets/sample_rfp_data.json pour le schéma complet.
2. Competitive Matrix Builder
Script : scripts/competitive_matrix_builder.py
Objectif : générer des matrices de comparaison de fonctionnalités, calculer des scores concurrentiels, identifier les différenciateurs et vulnérabilités.
Scoring des fonctionnalités : Full (3), Partial (2), Limited (1), None (0).
Utilisation :
python scripts/competitive_matrix_builder.py competitive_data.json # human-readable
python scripts/competitive_matrix_builder.py competitive_data.json --format json # JSON output
La sortie inclut : matrice de comparaison de fonctionnalités, scores concurrentiels pondérés, différenciateurs, vulnérabilités et win themes.
3. POC Planner
Script : scripts/poc_planner.py
Objectif : générer des plans POC structurés avec calendrier, allocation de ressources, critères de succès et scorecards d'évaluation.
Découpage par phase par défaut :
- Week 1 : Setup — provisionnement d'environnement, migration de données, configuration
- Weeks 2–3 : Core Testing — cas d'usage principaux, tests d'intégration
- Week 4 : Advanced Testing — cas limites, performance, sécurité
- Week 5 : Evaluation — finalisation scorecard, revue parties prenantes, go/no-go
Utilisation :
python scripts/poc_planner.py poc_data.json # human-readable
python scripts/poc_planner.py poc_data.json --format json # JSON output
La sortie inclut : plan POC par phases, allocation de ressources, critères de succès, scorecard d'évaluation, registre des risques et framework de recommandation go/no-go.
Bases de connaissances de référence
| Référence | Description |
|---|---|
references/rfp-response-guide.md | Bonnes pratiques de réponse RFP/RFI, matrice de conformité, framework bid/no-bid |
references/competitive-positioning-framework.md | Méthodologie d'analyse concurrentielle, création de fiches concurrentielles, traitement des objections |
references/poc-best-practices.md | Méthodologie de planification POC, critères de succès, frameworks d'évaluation |
Templates d'assets
| Template | Objectif |
|---|---|
assets/technical_proposal_template.md | Proposition technique avec executive summary, architecture de solution, plan d'implémentation |
assets/demo_script_template.md | Script de démo avec agenda, talking points, traitement des objections |
assets/poc_scorecard_template.md | Scorecard d'évaluation POC avec scoring pondéré |
assets/sample_rfp_data.json | Données RFP d'exemple pour tester l'analyzer |
assets/expected_output.json | Sortie attendue de rfp_response_analyzer.py |
Points d'intégration
- Marketing Skills - Exploiter la competitive intelligence et les frameworks de messaging de
../../marketing-skill/ - Product Team - Coordonner sur les éléments de roadmap signalés comme "Planned" dans l'analyse RFP depuis
../../product-team/ - C-Level Advisory - Escalader les opportunités stratégiques nécessitant une implication exécutive depuis
../../c-level-advisor/ - Customer Success - Transmettre les résultats POC et critères de succès au CSM depuis
../customer-success-manager/
Last Updated : February 2026 Status : Production-ready Tools : 3 scripts d'automatisation Python References : 3 documents de base de connaissances Templates : 5 fichiers d'assets