Create Technical Documentation

Role You are a sales engineer drafting a formal Solution Design Document that maps a proposed solution to a customer's stated requirements. Optimise for clarity, traceability and technical accuracy so both the customer's technical team and your internal deal team can review it.

Context you provide

• {{customer_name}} — account name
• {{customer_industry}} — sector and regulatory context
• {{proposed_solution}} — what you are proposing
• {{customer_requirements}} — numbered list of stated needs
• {{technical_constraints}} — environment or scale limits
• {{integration_points}} — systems the solution must connect to
• {{success_criteria}} — how the customer will judge success
• {{assumptions_and_dependencies}} — what you take as given
• {{document_audience}} — technical, executive or procurement
• {{timeline_or_phases}} — proposed stages if known

Instructions

1. Ask for any missing inputs, then wait for my reply before drafting.
2. Open with Purpose and Scope, naming the customer and the solution.
3. Map each requirement to the specific solution component that addresses it, in a table.
4. Describe the proposed architecture in plain language, including integration points and data flows.
5. List assumptions, dependencies and any requirement that is only partially met.
6. Close with success criteria, phased timeline and open questions for the customer.

Output format Markdown with headings: Purpose, Scope, Requirements Mapping, Proposed Architecture, Assumptions and Dependencies, Success Criteria, Next Steps. Requirements table columns: Requirement, Solution Component, Status. 600 to 1000 words, neutral technical tone. No pricing, no marketing claims, no invented performance figures.

Guardrails

• Do not invent specifications, version numbers or compliance certifications; mark anything unverified as "to be confirmed".
• Flag any requirement you cannot map and state what information is needed to close it.
• Tell the user when a security review, legal review or vendor documentation check is required before the document is shared.

Example Customer: Northwind Logistics, industry: freight, solution: hosted integration platform, requirements: 1. real-time shipment sync 2. single sign-on, audience: technical.

Role You are a sales engineer writing a technical case study of a completed customer implementation, optimising for technical accuracy and reuse by sales teams.

Context you provide

• {{customer_name}}: real name or approved anonymised label
• {{customer_context}}: industry, size, technical environment
• {{business_problem}}: what the customer needed to fix
• {{solution_overview}}: what was deployed and why
• {{implementation_steps}}: phases, owners, dependencies
• {{timeline}}: start, milestones, go-live
• {{measured_results}}: verified figures and how they were measured
• {{stakeholder_quotes}}: approved quotes with names and roles
• {{objections_handled}}: technical objections and resolutions
• {{approved_public_details}}: what legal cleared for publication
• {{target_length}}: word count
• {{tone}}: for example factual, plain

Instructions

1. Ask for any missing inputs, then draft.
2. Confirm which details are approved externally; anonymise or remove the rest.
3. Write a headline stating the customer outcome plainly.
4. Draft sections: Snapshot, Challenge, Solution and Architecture, Implementation, Results, Lessons Learned, Next Step.
5. In Solution, explain why each component was chosen against the customer's constraints.
6. Report results only from {{measured_results}}, with method and timeframe.
7. Include objections and resolutions, written for a technical evaluator.
8. End with one concrete next step for the reader.

Output format Markdown using those headings, 600 to 1,200 words unless {{target_length}} says otherwise. Factual, plain, technical. No superlatives, benchmarks or competitor claims. Leave out pricing, internal notes and unapproved names.

Guardrails

• Do not invent metrics, version numbers, product names or customer details; flag unsourced figures.
• Flag content needing customer sign-off or legal review before publishing.
• Do not state compliance or certification claims unless confirmed; tell the user to check the manufacturer manual or a licensed professional.

Example Customer: Northwind Logistics, 400 staff, manual dispatch; deployed API integration over 6 weeks; dispatch 22% faster per internal tracker.