See what the workflow prepares
Illustrative example. Sample notes, sample services, and sample pricing rules. This is not a customer result.
Discovery call notes
A software firm’s notes from a call with a regional distributor. “Staff in our three warehouses retype orders from our customer portal and from Shopify. There is a wholesale channel too, but I need to confirm the platform. We want the retyping to stop before the late-November peak. Do not replace the warehouse system. Our IT lead has to approve anything that connects to production. I want the operations manager to see open orders, exceptions, and work waiting on the warehouse. A colleague mentioned an app for pickers. I have not decided if we need it. We do not have a budget figure yet, and I still need to confirm who will sign.”
| Item | Captured detail | Standing |
|---|---|---|
| Objective | Stop retyping orders from the customer portal and Shopify into the current warehouse system. | Confirmed |
| Constraint | Keep the current warehouse system. | Confirmed |
| Constraint | The IT lead approves any production connection. | Confirmed |
| Timing | Before the late-November peak. No calendar date was given. | Window confirmed. Date unanswered. |
| Wholesale channel | Mentioned. Platform name not given. | Unanswered |
| Operations view | Open orders, exceptions, and work waiting on the warehouse. | Confirmed as a request |
| Picker app | Raised by a colleague. The prospect has not decided. | Suggestion. Not confirmed. |
| Budget | No figure. | Unanswered |
| Signer | Who will approve the proposal is still open. | Unanswered |
Approved services in this example
The sample catalog has three services. Anything outside the list stays unmapped.
- Named-channel order intake. Connect one named sales channel to the existing warehouse system. Includes field mapping, an exception queue, and two weeks of hypercare.
- Additional named channel. The same intake for one further named platform.
- Operations exception view. A read-only screen for one operations site, using the agreed sources. No write-back to the warehouse system.
A picker app and a warehouse replacement are not on this list.
| Request | Mapping |
|---|---|
| Customer portal | Named-channel order intake. Confirmed fit. |
| Shopify | Additional named channel. Confirmed fit. |
| Wholesale channel | Not mapped. The platform was not named. |
| Operations view | Closest service is the operations exception view. The request names three warehouses. The service is defined for one site, so the scope stays ambiguous. |
| Picker app | Not mapped. No approved service. |
| Replace the warehouse system | Excluded. It conflicts with a confirmed constraint and is not an approved service. |
Draft for review
Scope
Connect the customer portal and Shopify to the existing warehouse system so those orders are no longer retyped. The warehouse system stays. Production access waits on the IT lead. The wholesale channel stays out of scope until the platform is named. The picker app stays out of scope.
Deliverables
For the portal and for Shopify: the channel connection, field mapping, and an exception queue, plus the two weeks of hypercare included in the intake service. The operations view is described as a candidate. It is not a committed deliverable while the one-site question is open.
Assumptions
The current warehouse system remains the system of record. The portal and Shopify are the two named channels. If the operations view is added later, it is read-only. The IT lead will grant the access the integration needs.
Exclusions
Warehouse replacement. The unnamed wholesale platform. A picker app. Write-back from an operations view into the warehouse system. Hypercare after the included two weeks, because no further rate was supplied. Third-party license fees and travel, because no rates were supplied.
Timeline
The notes give a window: before the late-November peak. The draft records that window and does not turn it into a promised date. One possible sequence — complete the two named channels, then revisit the operations view — is marked as a suggestion, not a commitment.
Sample pricing rules
These rules belong to the illustration. They are not Tyon prices and not a fee charged to a real client.
- First named channel: 18,000.
- Each further named channel: 7,500.
- Operations exception view, read-only, one site: 9,500.
- Leave an unnamed platform unpriced.
- Leave a request unpriced when it has no approved service or no rate.
- Apply no discount.
- When the stated scope does not match the unit on the rate card, flag the line and leave it unpriced.
| Line | Rule applied | Result |
|---|---|---|
| Customer portal | First named channel | 18,000 |
| Shopify | Additional named channel | 7,500 |
| Wholesale channel | Unnamed platform | Not priced |
| Operations view | Rate is for one site. Three warehouses were stated. | Not priced. Scope ambiguous. |
| Picker app | No approved service and no rate | Not priced |
| Discount | Rules allow none | None applied |
The lines the rules can price add up to 25,500. That is a subtotal of priced lines. It is not a proposal total. Flagged lines stay outside it.
Still open, and who decides
The draft lists the unanswered items beside the priced lines: the wholesale platform, whether all three warehouses belong in the operations view, whether a picker app is required, the budget, the signer, and the exact date inside the late-November window.
Status: ready for the responsible person. The proposal has not been sent. Human review is required before sending.
Proposal outline and approval checklist
Copy this outline. The sample answers are from the illustration above. They are not a client proposal and not Tyon prices.
PROPOSAL OUTLINE Label: illustrative sample 1. Confirmed facts Stop retyping orders from the customer portal and Shopify. Keep the current warehouse system. The IT lead approves any production connection. 2. Suggestions, not requirements A colleague mentioned a picker app. The prospect has not decided. 3. Unanswered Wholesale platform. Budget. Signer. Exact date inside the late-November window. 4. Approved-service mapping Customer portal: named-channel order intake. Shopify: additional named channel. Wholesale channel: not mapped. Platform not named. Operations view: ambiguous. The request names three warehouses. The service is defined for one site. Picker app and warehouse replacement: not approved services. 5. Pricing rules applied Price only a line with a supplied rate and a matching unit. Leave unnamed platforms, missing rates, and ambiguous scope unpriced. Do not invent a discount. Priced lines in this sample: 18,000 and 7,500. Subtotal of priced lines: 25,500. Not a proposal total. 6. Draft sections Scope. Deliverables. Assumptions. Exclusions. Timeline. Pricing. Open questions. APPROVAL CHECKLIST The reviewer checks each item before the proposal can be sent. - Every priced line uses a rate from the supplied rules. - No unapproved service is written as a deliverable. - Suggestions are still labelled as suggestions. - Unanswered items are listed, not filled in. - The person named to approve it has reviewed this draft. Status in this sample: ready for that person. Not sent.
How the workflow works
-
1
Read the agreed sources
Use the discovery notes, the approved service descriptions, the proposal template, and the pricing rules. Those are the only commercial inputs.
-
2
Extract the project facts
Pull out objectives, requirements, constraints, and timing. Mark each item confirmed, a suggestion, or unanswered.
-
3
Map to approved services
Match confirmed requests to services on the approved list. Leave a request unmapped when no service fits, and say why.
-
4
Apply the pricing rules
Price only where a supplied rule gives a rate and the scope matches that rate. Flag a missing rate or an ambiguous scope, and leave that line unpriced.
-
5
Fill the template
Prepare scope, deliverables, assumptions, exclusions, timeline, and pricing, with the open questions attached. A suggestion stays labeled as a suggestion.
-
6
Hold for approval
Give the draft to the responsible person. The proposal is sent only after that person approves it.
The workflow does not invent a service, a date, a discount, or a rate. Your team defines which fields must be confirmed before a draft is allowed to go for approval.
Measure the value
Two counts tell you whether the draft is faster to finish and cleaner when it arrives for approval.
Drafting time, including review and corrections
Keep one log on the proposal. Each person who drafts, reviews, or corrects adds an entry with their name, the date, the minutes, and the kind of work: drafting, review, or correction.
Start when the discovery notes and the agreed source documents are available. Stop when the responsible person approves the draft for sending. Add every entry in between. The first version is not the end of the clock.
Leave waiting time off the log. Minutes spent waiting for the prospect, or for someone outside the drafting work, are not drafting time.
Revisions required before approval
A revision is one return of the draft for changes that must be made before the responsible person will approve it. Count returns, not individual comments. Several comments handled in the same return are one revision. Define that once and keep the definition.
On each return, record the reason: a confirmed fact was missed, a suggestion was written as a requirement, an open question was filled in, a service was outside the approved list, a price broke the supplied rules, or ambiguous scope was still priced.
How to add the minutes
This counting example shows the arithmetic. It is not a result from a client project.
The author logs 80 minutes drafting. The reviewer logs 30 minutes and returns the draft because a suggestion was written as a requirement. The author logs 25 minutes of corrections. The reviewer logs 15 minutes and approves the draft. Drafting time is 150 minutes. Revisions before approval: 1.
Compare proposals of a similar type, length, and approver from before the workflow and after it. Report the median drafting time and the median revision count. Keep the proposal type on the log so a large engagement is not compared with a small one. Collect that comparison before you claim a change.
Build it around the proposal you already send
This is a proposed implementation for one kind of proposal. You provide the discovery notes you already keep, the service descriptions you have approved, the template you send, and the pricing rules to apply. The workflow fills that template and lists anything it cannot resolve. The person you name approves the draft before it can be sent.
A connection to a notes tool, a document system, or a CRM is specified in the project. It is not assumed on this page. Related patterns are on AI automation use cases.
Limit: the workflow uses only the notes, service list, template, and pricing rules you supply. It does not invent a service, a date, a discount, or a rate. A notes tool, document system, or CRM connection is specified in the project.
Suitable measures are drafting time, including review and corrections, and the number of returns before approval. Compare similar proposals from your own before-and-after log. This page does not report a customer result.
Start with one proposal type and a written set of pricing rules. See pricing and weekly client reporting.