commercial-proposal-from-brief

Files (2)

• SKILL.md
• proposal-template-fr.md · templates/

SKILL.md (first lines)

# Commercial Proposal From Brief

Use this skill when the user provides a messy discovery brief, questionnaire answers, call notes, or a PDF example and wants a **clean commercial proposal** in the same spirit as the TSARAG VTC proposal.

## Goal

Transform raw discovery material into a proposal that:
- sounds clear, credible, and commercial
- shows that we understood the client
- maps pain points → solution
- explains the customer/admin/operator flows simply
- lists key features without fake precision
- ends with a clear next-step process

## Default style

Unless the user asks otherwise:
- write in **French** if the user speaks French
- keep the structure compact and business-ready
- prefer **simple / lean V1** over bloated scope
- do **not** invent pricing certainty or fake technical certainty that the brief does not support
- when the brief is sparse, you may still propose a **strong recommended scope** based on the business type, as long as you clearly separate **confirmed facts**, **recommended features**, and **open questions**
- explicitly separate **confirmed facts**, **reasonable assumptions**, and **open questions**

## Important correction — sparse briefs still require proactive solution design

If the brief is minimal (example: sector + team size + existing tool), do **not** stay too generic.
You should infer a credible commercial proposal from the business model and propose concrete, high-value features that are well-adapted to that sector.

Example for a high-end restaurant:
- online table reservation
- reservation confirmations and reminders
- Telegram / WhatsApp concierge-style reservation bot
- elegant website with menu, events, private dining, gallery, contact
- QR code menu
- review / feedback flows
- CRM-style guest notes and VIP preferences
- internal notifications for reservations, cancellations, special requests
- lead capture for events and private bookings
- multilingual experience if relevant

Rule:
- be concrete enough to be commercially compelling
- but mark unconfirmed items as **recommandé**, **option**, or **à confirmer** instead of presenting them as already requested facts

## Source model to imitate

The reference proposal has this logic:
1. Cover / title
2. What we understood + what we propose
3. How it works (client / operator journeys)
4. Key features
5. Operational view or concrete interface/process example
6. Process and next steps

Do **not** copy wording mechanically. Recreate the structure and selling logic from the brief.

## Mandatory workflow

### Step 1 — Extract the brief

Turn the raw input into these buckets:
- company / business model
- current operations
- online presence
- offers / services
- pricing model
- booking flow
- tools currently used
- team / roles
- main pain points
- missing information / unanswered questions

### Step 2 — Challenge scope first

Before drafting, identify the **simplest credible offer**.

Always ask internally:
- what is the leanest version that creates visible value fast?
- what should stay manual in V1?
- what is attractive in sales language but risky in delivery?

If the raw idea is too large, the proposal should still present a coherent solution, but phrased as:
- **V1 included**
- **optional next phase**
- **to clarify before commitment**

### Step 3 — Build the proposal around business problems

Write the proposal as a mapping:
- current friction
- proposed improvement
- expected operational benefit

Strong pattern:
- “Aujourd’hui … / Demain …”
- “Problème / Solution proposée / Impact”
- “Ce que nous avons compris / Ce que nous mettons en place”

### Step 4 — Write concrete usage flows

Always include the main journeys in simple language, for example:
- client books via website
- client books via Telegram / WhatsApp / form
- dispatcher/admin manages requests
- operator/driver/provider receives and confirms jobs

The goal is clarity, not exhaustive specs.

### Step 5 — List features with discipline

Include only features supported by the brief or clearly marked assumptions.

Feature lists should be grouped by theme, for example:
- website / visibility
- booking / qualification
- admin operations
- automation / notifications
- payment / invoicing

From bmoby/team-hermes-skills, MIT.

More from bmoby/team-hermes-skills