From customer brief to proposal, delivery and next action
A proposal should connect a customer's problem to a specific decision and an owned next action. This playbook keeps the brief, promises, delivery format and approved version together so the receiving team can act on the accepted scope.
The workflow is an editorial operating design, not a product default or a customer success story. The example roles can be replaced with your actual team, including one person holding several roles. Preserve the distinct responsibilities even when the team is small.
1. Approve a brief before drafting
Record the customer task, relevant context, proposed scope, assumptions, exclusions, timeline, pricing basis and requested decision. Mark unresolved items explicitly. A blank price or unconfirmed date should remain unresolved internally rather than becoming an invented certainty in generated slides.
Customer / opportunity ID:
Problem and desired customer decision:
Approved facts and context sources:
Proposed scope and deliverables:
Assumptions and exclusions:
Pricing basis and approved amount, if agreed:
Timing and responsibilities:
Unresolved items and owner:
Required delivery format / destination application:
Author, factual reviewer and delivery owner:
Keep unnecessary personal or confidential details out of drafting inputs. The author should know which information is approved for the customer artifact and which belongs only in the internal record.
2. Select the missing production capability
Use Gamma as a drafting candidate, Beautiful.ai as a layout candidate, Canva for a wider visual workflow and Pitch for coordinated presentation production. These research angles overlap and require exact plan review.
If the current editor already produces an accepted customer copy, improve the outline and review process before adding another subscription. Compare Gamma vs Beautiful.ai, Gamma vs Canva and Beautiful.ai vs Pitch for the actual gap.
3. Review the draft for customer meaning
The factual reviewer should inspect each promise against the approved brief. Confirm names, numbers, dates, exclusions, responsibilities and any performance claim. Review the story from the customer's perspective: can the recipient explain what is proposed and what they must decide?
| Review failure | Required response |
|---|---|
| Unsupported claim or invented result | Remove it or obtain a valid supporting source |
| Unapproved price or date | Resolve with the accountable owner before sending |
| Missing material exclusion | Add it where the customer can understand it |
| Dense slide obscures the decision | Simplify the explanation or move supporting detail |
| Conflicting versions | Identify the approved source and retire the incorrect copy |
AI output is draft material. A polished layout is not evidence that a price was authorized or that a service team can meet the proposed date. Keep the reviewer distinct from the drafting step where practical.
4. Accept the customer deliverable
Produce the required browser view, PDF or editable PowerPoint during the pilot. Open it in the customer's destination application. Inspect headings, cost tables, fonts, links, notes and the exact elements the recipient must edit.
Gamma's export help describes presentation-based output and workspace branding behavior. Beautiful.ai documents eligible editable-PowerPoint plans and font-related differences. These are reasons to test the delivered file rather than approving only the editor preview. Gamma export and Beautiful.ai export
Use the delivery checklist and record the accepted output. For browser sharing, test the intended viewer role and determine whether forwarding is appropriate. Keep a dated customer copy when version history matters to the next team.
5. Send with a specific next decision
The delivery owner should state what the customer is being asked to do: confirm assumptions, approve a scope, choose an option or arrange a review. Set a realistic next review target and use the existing customer record to track the response.
A view count or link-open event is context for follow-up, not agreement. Do not mark the proposal accepted or authorize delivery solely because analytics show that someone opened it. Record the actual customer decision and any conditions.
If the proposal changes, identify the replacing version and what changed. Make the status of the older copy explicit so the customer and receiving team do not work from different promises.
6. Handoff the accepted scope
Opportunity / customer ID:
Approved proposal version and delivered artifact:
Customer decision and conditions:
Accepted scope, price basis and exclusions:
Promised timing and responsible roles:
Sending role / receiving role / backup:
Next action and review target in staffed hours:
Unresolved item and escalation owner:
Accepted by / accepted at:
The sending role remains responsible until the receiving team accepts usable context. Generate an ownership plan with the proposal template in the handoff planner. An attachment without an accepting role is an incomplete handoff.
7. Inspect ordinary and failure cases
Exercise a normal proposal, a late scope change, an absent reviewer, a broken shared link, a failed export and an after-hours acceptance. Check which version the customer receives and which promises the service team sees.
Sample repeated factual corrections, output repairs, unclear customer decisions and handoffs awaiting acceptance. Use those findings to improve the brief, template and role coverage before buying more AI or collaboration capacity.
Budget authors, required reviewers, brand controls, usage, setup and recurring revision in the cost planner. The useful purchase removes a documented production gap while preserving an accurate proposal and an accountable next action.
Evidence: official documentation reviewed October 12, 2026, plus editorial analysis. Illustrative scenarios and arithmetic are planning examples, not customer results or hands-on product benchmarks. Published plan details can change; confirm the account, region, billing period and deliverable before purchase.