| 1 | --- |
| 2 | style_id: solution-proposal |
| 3 | kind: style |
| 4 | summary: Client-facing proposal method that proves understanding first, then earns the work through a specific, costed plan. |
| 5 | keywords: [proposal, presales, bid, client, engagement] |
| 6 | --- |
| 7 | |
| 8 | # Solution Proposal — Style Specification |
| 9 | |
| 10 | > Method and design defaults only. No project communication contract, brand identity, page structure, or SVG prototypes. |
| 11 | |
| 12 | ## I. Style Overview |
| 13 | |
| 14 | | Property | Value | |
| 15 | |---|---| |
| 16 | | Style Name | Solution Proposal | |
| 17 | | Best Fit | Client proposals, presales solution presentations, tender and bid responses, statements of work, and vendor selection finals | |
| 18 | | Reusable Intent | Convince a buying group that their situation is genuinely understood and that this specific plan, team, and price will deliver — with commitments precise enough to sign | |
| 19 | | Sources | Authored in-repo as a bundled reference Style, 2026-08-07; distilled from presales and bid-response practice, not a single external document | |
| 20 | |
| 21 | ## II. Communication Method |
| 22 | |
| 23 | - **Preferred Mode**: pyramid |
| 24 | - **Argument Flow**: Lead with the client's situation in the client's own terms, state the recommended approach and what it will achieve, then support it with how the work is done, who does it, what it costs, and how risk is handled. Everything after the recommendation exists to make it credible and signable. When the buyer has published requirements, answer them on their terms and in a traceable order rather than reorganizing around what is convenient to present. |
| 25 | - **Page Message Discipline**: Give each page one commitment, one component of the approach, or one piece of proof, and title it with what the client gets rather than with a capability name. Keep a promise and its supporting mechanism on the same page. Never present a page whose subject is the vendor when the same space could carry the client's outcome. |
| 26 | - **Claim Discipline**: Keep understood requirement, proposed commitment, assumption, exclusion, and optional scope explicitly distinct — ambiguity here becomes a dispute later. Separate what is included from what is available at additional cost, state every dependency on the client, and never imply a capability, certification, reference, or resource that cannot be produced on request. Present references and case evidence with their actual scope rather than a flattering generalization. |
| 27 | |
| 28 | ## III. Page Role Vocabulary |
| 29 | |
| 30 | | Role | Communication Job | Evidence Obligation | Composition Tendency | |
| 31 | |---|---|---|---| |
| 32 | | Situation understanding | Show the client's reality is genuinely understood | Use the client's own facts, constraints, and language gathered in discovery, not a generic industry sketch | Lead with their situation; keep vendor presence minimal on this page | |
| 33 | | Requirement interpretation | Confirm what is being solved and to what standard | Restate stated and implied requirements with priority and success criteria; flag where interpretation was needed | Keep the client's framing visible and mark any reinterpretation openly | |
| 34 | | Recommended approach | State the plan and why it fits this client | Connect each element of the approach to a specific requirement or constraint | Make the recommendation dominant and its rationale visibly adjacent | |
| 35 | | Alternatives considered | Show the recommendation was chosen, not defaulted to | Give real alternatives with why they were set aside for this client | Compare on the client's decision axes, not on vendor preference | |
| 36 | | Solution architecture | Show what will actually be built or delivered | Depict real components, interfaces, and boundaries; mark what is existing, new, and third-party | Keep boundaries and ownership legible; avoid diagrams that hide the seams | |
| 37 | | Delivery plan | Show how the work reaches the outcome | Give phases, durations, dependencies, decision gates, and client involvement | Make sequence and critical dependency scannable without becoming a project schedule | |
| 38 | | Team and responsibility | Establish who does the work and who is accountable | Name real roles and allocation; distinguish named individuals from role placeholders | Keep accountability unmistakable rather than presenting an anonymous org shape | |
| 39 | | Proof and reference | Establish this has been done before | Give comparable engagements with scope, scale, outcome, and permission to reference | One relevant reference at real depth beats a wall of client marks | |
| 40 | | Commercial terms | State what it costs and what triggers payment | Give price basis, assumptions, inclusions, exclusions, and change mechanism | Keep the number and its basis together; never separate price from what it buys | |
| 41 | | Risk and mitigation | Show the hard parts are known and handled | Pair each real risk with likelihood, impact, mitigation, and owner including client-side risk | Keep risk and response in direct correspondence; do not sanitize the list | |
| 42 | | Assumptions and dependencies | Bound the commitment honestly | State every client dependency and assumption that price and schedule rest on | Give these a real page; they define the boundary of the promise | |
| 43 | | Next step | Make the decision easy to act on | Give the specific action, owner, and date that moves to contract or pilot | One dominant action; never end on a generic thank-you page | |
| 44 | |
| 45 | ## IV. Evidence & Data Expression |
| 46 | |
| 47 | - **Argument Trace**: Every commitment traces to a client requirement, and every capability claim traces to evidence that can be produced in diligence — a delivered engagement, a certification, a named resource, or a working artifact. Where the response is a partnership or a hire yet to be made, say so rather than presenting it as existing capacity. |
| 48 | - **Charts**: Use charts for the client's own data, projected outcomes, and delivery sequence. State the basis and assumptions of any projected benefit on the chart itself, distinguish modeled from measured, and keep comparison conditions matched. Never present a benefit curve without the assumptions that generate it. |
| 49 | - **Tables**: Use tables for requirement traceability, scope inclusion and exclusion, pricing breakdown, and responsibility assignment. Keep one row shape, mark optional and conditional items clearly, state units, currency, and validity period, and make the boundary between included and excluded impossible to misread. |
| 50 | - **Sources**: Attribute client-supplied facts to their discovery source, cite third-party benchmarks with date and scope, and reference prior engagements only with permission and accurate scope. Keep pricing validity dates and any rate basis visible. |
| 51 | - **Native Editability**: Prefer editable native tables and charts for pricing, scope, requirement traceability, and schedule — proposals are revised through negotiation and reissued, so these must be correctable in place. Keep an architecture diagram as editable shapes so scope changes can be redrawn rather than rebuilt. |
| 52 | |
| 53 | ## V. Visual System Defaults |
| 54 | |
| 55 | - **Preferred Visual Style**: soft-rounded |
| 56 | - **Composition**: Build each page around the client's outcome, with a stable position for the commitment line and a stable position for supporting evidence. Give the recommendation, commercial, and next-step pages room; let architecture and traceability pages carry structured density. Keep composition consistent enough that a document read offline navigates by position. |
| 57 | - **Density**: Proposals are read alone as often as presented, so pages must survive without narration. Keep the argument pages readable at a glance and let scope, pricing, and traceability pages carry real detail under one grid without dropping below legible scale or hiding a condition. |
| 58 | - **Decoration**: Professional and calm. Use gentle containers to group related commitments, hairline separation for structure, and restrained emphasis. Avoid heavy corporate ornament, stock imagery of handshakes and skylines, gradient banners, and decorative devices that inflate a thin proposal. Nothing should look more expensive than the work being proposed. |
| 59 | - **Color Behavior**: Keep a neutral professional field and reserve accent for the client's outcome and the decision points. Where a table distinguishes included, optional, and excluded scope, encode that distinction with label and position as well as color so it survives printing and forwarding. Any confirmed Brand or Deck identity replaces these tendencies — a client-facing proposal normally carries the vendor's own identity. |
| 60 | - **Typography Character**: Use a clear professional sans-serif with tabular figures for pricing and effort tables, comfortable reading size for offline review, and consistent treatment of terms, currency, and units. Keep hierarchy from weight and spacing rather than ornamental containers. Exact families remain current-project or resolved identity decisions. |
| 61 | |
| 62 | ## VI. Image & Icon Direction |
| 63 | |
| 64 | - **Preferred Image Rendering**: corporate-photo |
| 65 | - **Image Usage**: Use imagery where it carries the client's context or real delivery evidence — their environment, a comparable installation, a delivered artifact, or the actual team. Keep architecture, process, and responsibility structures as authored diagrams. Never use generic business imagery to pad a proposal. |
| 66 | - **Image Treatment**: Crop to the subject that supports the point, keep any embedded interface or document text legible in print as well as on screen, and caption with context and permission status. Use consistent framing throughout. Avoid full-bleed decorative imagery, and never show another client's confidential material or synthetic text inside generated images. |
| 67 | - **Icon Treatment**: Use one coherent icon family at consistent weight to mark recurring classes such as phase, role, or scope status, with fixed meaning throughout. Never let an icon alone carry an inclusion or exclusion that has commercial consequence. Avoid icon grids used as capability inventories and third-party logos implying partnership or certification that does not exist. |
| 68 | |
| 69 | ## VII. Review Focus |
| 70 | <!-- visual-review-trigger: explicit-user-only --> |
| 71 | > Apply this section only after the user explicitly activates visual review. It never triggers that stage. |
| 72 | |
| 73 | - Every page survives offline reading without a presenter, since proposals are forwarded and evaluated alone. |
| 74 | - The client's situation and language are visible early and dominate the vendor's presence. |
| 75 | - Included, optional, and excluded scope is unmistakable and does not depend on color alone. |
| 76 | - Price appears together with its basis, assumptions, validity, and what it buys. |
| 77 | - Assumptions, client dependencies, and exclusions occupy a real page rather than fine print. |
| 78 | - Requirement traceability is followable where the buyer published requirements. |
| 79 | - Pricing and effort figures align in tabular columns and remain legible in print. |
| 80 | - The closing page gives one concrete next action with an owner and a date. |
| 81 |