Leave with a proposal structure with scope, responsibilities and decision requirements.
Start with a real buying situation
For the worked example, the audience is the owner of a 60-person business. Their problem is that support requests arrive through personal messages and urgent issues lack a clear owner. The desired practical outcome is a documented escalation path and visible ticket ownership.
The example is deliberately bounded: business-critical systems cannot be changed during working hours. That condition should influence the promise, scope and next step rather than disappear from the marketing copy.
| Illustrative offer | a support and device-management service |
|---|---|
| Buyer question | Which incident last interrupted work, and how was responsibility assigned? |
| Possible evidence | an example ticket lifecycle with triage, handover and closure evidence |
| Useful asset | an incident escalation checklist |
How to complete your proposal brief
- Restate the buyer’s verified problem and desired result.
- Specify deliverables, responsibilities and exclusions.
- Describe the sequence and required client inputs.
- Separate fees and third-party costs.
- List acceptance criteria, open questions and the approval process.
Worked example
These entries are illustrative planning material, not research findings or customer results. Keep the structure and replace the content with verified details.
| Problem and desired outcome | Problem: support requests arrive through personal messages and urgent issues lack a clear owner. Desired result: a documented escalation path and visible ticket ownership. Confirm both with the buyer. |
|---|---|
| Deliverables and exclusions | a support and device-management service. Define supported devices, service hours, exclusions and escalation contacts. List exclusions rather than relying on assumptions. |
| Responsibilities and dependencies | business-critical systems cannot be changed during working hours. Name the client and supplier owners for each required input. |
| Fees and commercial assumptions | Use approved prices only. Define supported devices, service hours, exclusions and escalation contacts. The worksheet deliberately contains no invented market rate. |
| Acceptance and approval | Agree how to review an example ticket lifecycle with triage, handover and closure evidence and ticket age by priority, with priority definitions agreed first. List open questions, approvers and the next decision. |
Review before using it
A useful operational measure in this example is ticket age by priority, with priority definitions agreed first. That does not automatically make it a marketing attribution metric. Define the source, period and owner before drawing conclusions.
- Could delivery begin from this document without relying on undocumented promises?
- Check the delivery assumptions: Define supported devices, service hours, exclusions and escalation contacts.
- Use evidence rather than promises. Response time is not resolution time; do not imply they are interchangeable.
- Discuss the draft with someone who understands the buying situation. Start with: “Which incident last interrupted work, and how was responsibility assigned?”
- If the next step is a trial, define its purpose. One possible starting point is to review a limited device group and agree escalation responsibilities.
Common mistakes and a better review
Do not fill a missing fact with an impressive-sounding number. Mark it as an assumption, explain how you will check it and give that check an owner. A short, honest document is easier to use than an elaborate plan built on unknowns.
| Watch for | A persuasive proposal can still fail if nobody knows what is included. |
|---|---|
| A real buyer concern | Our existing IT person already handles everything. |
| Useful response direction | We can map the workload with them and identify gaps in cover; the conversation need not start with replacing anyone. |
| Evidence to collect | The buyer’s own account, an example ticket lifecycle with triage, handover and closure evidence, and records relevant to ticket age by priority, with priority definitions agreed first. |
Your working sheet
Write your own version below. Notes are saved on this browser when local storage is available. Use Download to keep a separate copy; avoid adding confidential information on a shared device.
Example: Problem: support requests arrive through personal messages and urgent issues lack a clear owner. Desired result: a documented escalation path and visible ticket ownership. Confirm both with the buyer.
Example: a support and device-management service. Define supported devices, service hours, exclusions and escalation contacts. List exclusions rather than relying on assumptions.
Example: business-critical systems cannot be changed during working hours. Name the client and supplier owners for each required input.
Example: Use approved prices only. Define supported devices, service hours, exclusions and escalation contacts. The worksheet deliberately contains no invented market rate.
Example: Agree how to review an example ticket lifecycle with triage, handover and closure evidence and ticket age by priority, with priority definitions agreed first. List open questions, approvers and the next decision.
Review your work
Tick only what you can support with your answer or practice. This is a reflection checklist, not an automated assessment.
Questions about this resource
How do I adapt this for my managed it services business?
Replace the audience, offer and evidence with your actual information. Begin with a recent buyer conversation about why support requests arrive through personal messages and urgent issues lack a clear owner, then check which assumptions match your business.
Is the filled example ready to publish?
No. It is a working example. Verify claims, permissions, prices, current capabilities and any customer information before using it externally. Response time is not resolution time; do not imply they are interchangeable.
What should I do after completing the worksheet?
Use it to make one decision or have one focused conversation. The intended output is a proposal structure with scope, responsibilities and decision requirements. Set a review date and update it when the evidence changes.
Illustrative business worksheet. No customer results, market rates, traffic volumes or performance benchmarks are implied. About these resources.