Home » Improve Quote-to-Order Flow in an Engineering Service Business
Improve Quote-to-Order Flow in an Engineering Service Business
Contents
When an engineering quote takes too long, the delay often sits between teams: a request is incomplete, technical review waits for an engineer, costing waits for a process assumption, or an approval has no named owner. You can find the constraint by tracing one request type from receipt to the customer’s decision. Record when work waits as well as when someone works on it. Then change one handoff and check that the quote remains technically and commercially sound.
Map the information and decisions needed to move an engineering request to a complete response.
Choose a request type and define the finish line
Start with a repeatable request, such as a quote for a drawing change, inspection service, fixture modification, or small engineering study. Do not combine unlike work in one measure. A repeat service estimate may need a short scope check; a custom design request may need calculations, safety review, supplier input, and several approvals.
Define the start as the time the request first arrives. Define “complete” as a released quote with scope, exclusions, assumptions, price, schedule, and required approvals. A receipt confirmation is not a complete response. Decide whether your measure ends at quote release or at the customer’s accept/decline decision. Keep both dates if you want to separate your team’s response from the customer’s decision time.
For each request, identify its type, required inputs, decision owner, and priority rule. “Urgent” is not a useful priority rule unless someone can explain what qualifies, who can approve the exception, and what work will move as a result. Use an access-controlled record for customer names, drawings, confidential pricing, and commercial terms.
Map the actual information flow
A value-stream map shows the steps and information needed to deliver a product or service. The Lean Enterprise Institute recommends starting with the current state: observe how work actually moves, then use a future-state map to plan a specific change. For an engineering request, map both the request and its decisions. A stage is not complete because someone forwarded an email; it is complete when its required output is present and the next owner accepts the handoff.
Request-to-completion swimlane: roles, work, and the handoff check
Role or lane
Intake and triage
Technical review
Cost and capacity
Approval and release
Customer response
Sales or request owner
Log request, receipt time, type, due date, and customer contact
Clarify missing requirements; record customer-wait start and next update
Confirm scope assumptions and requested options
Coordinate approval; issue the controlled quote version
Record accepted, declined, revised, or pending and next action
Engineering
Confirm a technical reviewer and required inputs
Check feasibility, drawings, interfaces, risks, and exclusions
Supply hours, method, equipment, or supplier assumptions
Approve technical content where required
Answer technical questions through the controlled record
Operations or costing
Identify capacity and cost-data owner
Flag process constraints and unavailable inputs
Provide dated labor, material, supplier, and capacity basis
Confirm schedule and commercial approval limits
Support a revision when scope or capacity changes
Draw the current state from recent examples, not from a procedure that the team rarely follows. Include email waits, missing information, approval loops, quote revisions, and work that is paused until a customer answers. Record process time separately from elapsed time. Process time is hands-on work. Elapsed lead time is the time from the agreed start to finish, including queues and external waits.
At each handoff, define the acceptance check. For example, engineering should receive a current drawing revision, required interfaces, intended use, and the requested decision date. Costing should receive an approved technical scope and dated assumptions. The person who sends work should remain responsible for unresolved questions until the next owner confirms receipt.
Separate internal queues from customer waits
Keep a timestamp for request receipt, first substantive response, request-complete status, each stage entry and exit, clarification sent, customer response, quote release, and final decision. Record elapsed hours or days using one calendar rule. If the office closes overnight or for holidays, state whether your measure uses clock time or business time; do not compare the two as if they were equivalent.
Classify each pause with a reason, next owner, and next update date. Useful states include “awaiting customer drawing,” “awaiting supplier cost,” “engineering review,” and “approval required.” Avoid a generic “on hold.” The classification helps a team distinguish a real customer delay from an internal handoff that nobody owns.
The U.S. EPA’s Lean waste reference includes service examples such as order-entry, design, and engineering errors, response-time waiting, approvals, repeated data entry, and excessive reporting. Use these as prompts to inspect the work. They are not proof that a particular delay is waste: a technical review, legal check, or customer clarification may be necessary to produce a safe and accurate quote.
Work five illustrative tickets
The following example uses invented drawing-change requests to demonstrate measurement. It is not a company case, measured result, target, or promise. The elapsed time is calendar time from receipt to quote release. Touch time is estimated hands-on effort recorded across the request. Customer-wait time remains inside elapsed lead time and is shown separately. These figures help explain the calculation only.
Illustrative sample only — five hypothetical engineering quote tickets
Ticket
Received
Assigned
Review
Clarification or rework
Released
Elapsed lead time
Touch time
Recorded pause
E-101
Mon, 09:00
Mon, 10:00
Mon, 13:00
None
Tue, 09:00
1 day
45 min
None recorded
E-102
Mon, 11:00
Tue, 09:00
Tue, 13:00
Customer drawing received Wed, 14:00
Thu, 11:00
3 days
70 min
1 day 1 hour, awaiting customer
E-103
Tue, 08:00
Tue, 15:00
Thu, 09:00
Cost assumption corrected Fri, 10:00
Sun, 08:00
5 days
120 min
1 day, supplier cost; 1 day, approval
E-104
Wed, 10:00
Fri, 09:00
Mon, 12:00
Customer scope confirmed Tue, 10:00
Following Thu, 10:00
8 days
95 min
1 day, awaiting customer; 1 day, approval; other queue time shown by stage timestamps
E-105
Thu, 08:00
Following Mon, 09:00
Following Wed, 14:00
Revision and costing loop; corrected assumptions Fri
Day 11, Mon 08:00
11 days
160 min
3 days, internal queue; 2 days, revision loop; weekend calendar time remains in lead time
For E-104, elapsed lead time is 8 calendar days: Wednesday 10:00 to the following Thursday 10:00. Its 95 minutes of touch work is 1 hour 35 minutes. The difference is not automatically “waste”; it includes queue time, customer time, nights, and any necessary review. It does show why a touch-time estimate alone cannot answer how long a customer waits.
Sorted from shortest to longest, the five lead times are 1, 3, 5, 8, and 11 days. The median is 5 days, the range is 1–11 days, and the mean is 5.6 days: (1 + 3 + 5 + 8 + 11) / 5. The mean moves when one long request changes, so show the count and distribution with it. In a real review, use enough comparable requests to reveal a pattern and label incomplete or pending requests separately rather than dropping them silently.
Compare similar request types, calendar rules, and case counts.
Median (days)
5
3
Did the middle request move, or did the mix change?
Longest request (days)
11
8
Check the oldest case and its actual blocking reason.
Touch time and quote quality
Measure locally; not supplied by this fictional chart
Measure locally; not supplied by this fictional chart
Confirm any speed change did not increase corrections, risk, or missed scope.
The trial values above are an invented illustration of how to display a comparison. They do not establish that a real intervention reduces lead time. A real before-and-after review must state its dates, sample sizes, case mix, exclusions, and quality checks. If the sample is small or demand changed, report that limitation instead of claiming causation.
Use a request board that helps work move
A shared board can show where a request is and who owns the next action. Keep the controlled drawing, commercial record, and customer data in approved systems; the board can point to those records without exposing sensitive details. Start with these 12 fields:
12-field engineering request board
#
Field
Use
1
Request ID
Use a non-sensitive identifier that links to the controlled record.
2
Received date and time
Start the lead-time clock consistently.
3
Request type
Separate repeat quotes from custom engineering work.
4
Current stage
Show intake, engineering, costing, approval, or customer decision.
5
Ready status
State whether required inputs are complete for the current stage.
6
Next action
Name the specific work needed to advance the request.
7
Next owner
Assign one person or role accountable for that action.
8
Target date
Show the agreed internal due date or customer commitment.
9
Priority reason
Record the approved rule behind an exception.
10
Blocked reason
Identify the actual missing decision or input, or leave blank.
11
Next update date
Make customer and internal follow-up visible.
12
Last stage change and touch minutes
Review queue age and accumulate hands-on effort consistently.
Use the board in a short daily review. First look at requests that are overdue, blocked, or aging past the team’s agreed review point. Confirm the next action, owner, and update date. Check whether work is actually ready before pulling another request into engineering or costing. Then review new requests and priority exceptions. A stable routine helps expose overloaded stages; it does not require every technical task to be identical.
Use pull carefully in a service workflow
In factory pull production, a downstream process signals an upstream process to replenish a needed quantity. The Lean Enterprise Institute describes this production-control method in terms of downstream demand and upstream supply. A custom quote queue differs: requests have different scope, risk, skill requirements, and customer commitments. Do not copy a factory kanban card and assume it controls engineering capacity.
You can still apply the underlying discipline in a limited way. Make “ready for engineering” depend on a complete intake check. Set a visible cap on the number of active requests only after the team reviews capacity and risk. When a reviewer finishes one request, the next ready item can be selected using the agreed priority rule. Escalate a safety-critical or contractual deadline through a defined exception path. Never delay required review simply to meet a queue limit.
Keep this flow separate from factory takt time unless requests are genuinely repeatable and demand is stable enough for that rate to be meaningful. For a custom engineering request, a service-level commitment or aging threshold is usually a clearer control than a target that implies identical work content.
Test one change and protect quote quality
Choose a change tied to the observed queue: an intake checklist if requests repeatedly miss drawing revisions, a named reviewer rota if technical work waits unassigned, or a daily aging review if approval ownership is unclear. Change one condition at a time where practical. Before the trial, define the request type, dates, sample, measure, and quality guardrails.
Review lead-time distribution, first-response time, touch effort, correction rate, number of quote revisions, missed assumptions, and customer-update reliability. A faster release that needs correction or omits exclusions is not an improvement. Stop and investigate if the team skips required design, safety, export, legal, or commercial review; if the queue cap hides urgent work; or if the board exposes confidential information.
Do not force a single queue for work that needs different specialist skills or independent approval. Route that work by capability while keeping one visible owner for the request. If customer inputs are missing, send a specific question, record the wait state, and set a follow-up date. If the request changes scope, create a new controlled revision and reset only the measures your policy defines; keep the original timestamps for traceability.
Start with one request and one measure
Select one engineering quote or service-request type.
Assign an owner to map the request from receipt to release.
Agree on start, finish, business-time rule, and stage definitions.
Collect recent timestamps, touch effort, pause reasons, and corrections.
Separate customer waits from internal queues without removing either from total lead time.
Choose one handoff change and one quality guardrail.
Review comparable requests after the trial and record what changed in the work.
Record the first receipt timestamp and the next owner before discussing solutions. For requests that are already accepted and need engineering-change control through CAD release and the shop, use the engineering change workflow. For internal engineering-service backlog and rework, see the engineering-service backlog guide.
