Fast quoting is not always the right outcome
For straightforward work, speed matters. If the job is familiar, the pricing model is proven and delivery is predictable, there is usually no reason to slow the quote down with extra internal checks.
But unusual work should not follow the same path.
The problem is not just that complex quotes take longer. The real issue is that some jobs carry risks your normal quoting process is not designed to catch. A quote can go out quickly, get accepted, and only then does the business discover that the margin was too thin, the scope was unclear, the access conditions were difficult, or the customer’s terms created obligations nobody properly reviewed.
At that point, the quote is no longer just an estimate. It has become a commitment that operations now has to deliver.
A good quote approval workflow exists to stop that happening. It creates a clear internal review step for work that sits outside normal pricing, delivery or contract patterns, so the business can make deliberate decisions before promising something it may regret later.
Why risky quotes cause problems downstream
When a bad job is accepted, the damage usually shows up somewhere else.
It might look like:
- delivery teams inheriting unrealistic allowances
- unexpected labour or materials that were never priced
- site conditions making the job harder than assumed
- project managers negotiating around commitments that should not have been made
- disputes about what was or was not included
- low-margin work absorbing management time
- payroll, scheduling or procurement teams dealing with avoidable exceptions
From the outside, this can look like a delivery problem. In reality, it is often a quote governance problem.
The quote was treated as though it was standard work when it was not.
That distinction matters. If every quote follows the same workflow, then unusual jobs are forced through a process designed for normal ones. The system never stops to ask whether the business should review technical feasibility, commercial risk or contractual exposure before sending the quote.
Not all quotes should follow the same path
A practical quote process usually needs at least two paths:
- a standard path for low-risk, repeatable work
- a review path for non-standard or higher-risk work
That does not mean creating unnecessary friction. It means deciding in advance which conditions justify extra review.
Without that, approval becomes personality-driven.
One estimator sends unusual work for review because they are cautious. Another sends similar work straight out because they are confident or under pressure. A manager gets involved only when something “feels off”, which sounds workable until the wrong job slips through.
A better approach is to define explicit approval triggers.
The key question is not “Do we trust the person preparing the quote?”
It is “What characteristics of this job mean the business should pause before making a commitment?”
The approval triggers should be predefined
Approval rules work best when they are based on visible conditions in the quote, not on who happens to be involved that day.
Common triggers include:
- margin below an agreed threshold
- custom or poorly defined scope
- non-standard inclusions or exclusions
- difficult site access or delivery constraints
- unusual install conditions
- customer-supplied contract terms
- dependencies on third parties
- incomplete technical information
- significant procurement uncertainty
- pricing based on assumptions rather than confirmed inputs
- variations from standard service levels or warranty commitments
The exact triggers depend on the business, but the principle stays the same: if a quote falls outside normal delivery patterns, the system should require review before it can be sent.
That review should not rely on memory.
If someone needs to remember that “jobs like this usually need Bob to check them”, the process is already fragile. The workflow should identify the condition and route the quote accordingly.
The most useful triggers are operational, not just financial
Low margin is an obvious trigger, but it should not be the only one.
Some risky quotes look commercially acceptable on paper and still become bad jobs because the real problem sits elsewhere.
For example:
- The gross margin looks fine, but access is restricted and install time is likely understated.
- The customer wants a custom configuration the delivery team has not done before.
- The quote assumes site readiness, but that assumption has not been confirmed.
- The contract includes liquidated damages, reporting obligations or response-time requirements that change the delivery risk.
- The work depends on information that is still incomplete, but the quote is being pushed out to meet a deadline.
These are not just pricing issues. They are commitment issues.
A good approval workflow should catch both commercial risk and delivery risk, because operations wears the consequences of both.
Separate technical approval from commercial approval
One common failure is treating approval as a single generic sign-off.
In practice, risky quotes often need different types of review from different owners.
Technical review
Technical review answers questions like:
- Is the scope actually deliverable as quoted?
- Are the assumptions realistic?
- Do we have enough information to commit?
- Are there known access, site or sequencing risks?
- Does the delivery team need conditions, qualifications or staged assumptions included?
This review is about whether the promised work makes sense operationally.
Commercial review
Commercial review answers questions like:
- Is the margin acceptable for the level of risk?
- Are allowances realistic?
- Are there unusual payment terms or obligations?
- Does the customer contract shift too much risk onto the business?
- Has the quote included the cost of the complexity being accepted?
This review is about whether the job is commercially worth taking on in the form proposed.
Sometimes one person can do both reviews. Often they should not. A technically sound job can still be commercially unattractive, and a commercially attractive job can still be operationally dangerous.
If the workflow treats all review as one vague approval step, these distinctions get lost.
The quote record should show why review was required
A useful approval workflow does more than stop a quote from being sent. It also records why the quote entered review in the first place.
That matters for three reasons.
First, it gives the reviewer context. They should not have to read the whole quote and guess what triggered escalation.
Second, it creates consistency. If the system records that the quote was flagged because margin fell below threshold and access conditions were unconfirmed, the review stays anchored to real issues rather than drifting into a general discussion.
Third, it creates an audit trail for future handover. If the job is won, operations can see what risks were identified and what assumptions were approved.
In practical terms, the quote record should include:
- the specific trigger or triggers activated
- who reviewed it
- what decision was made
- any conditions attached to approval
- any required changes before send
- any assumptions that must remain visible to the customer
That is far more useful than a simple “approved” status.
Approval outcomes should be explicit, not implied
A risky quote should not move forward on the basis of silence, a chat message or a verbal “looks fine”.
The outcome needs to be visible in the workflow.
Typical approval outcomes might include:
- approved to send
- approved to send with conditions
- revise and resubmit
- additional technical information required
- contract review required before send
- declined to quote under current assumptions
These outcomes are operationally different. They affect what happens next.
If approval is treated as an informal conversation rather than a state in the process, the next person is left to interpret what was meant. That is how qualifications disappear, assumptions get lost, and revised pricing never makes it back into the quote properly.
The workflow should make the next action clear.
Design the workflow around decisions, not just stages
A lot of quote processes are built as status lists: drafted, pending, approved, sent. That looks neat, but it often hides the logic.
For non-standard work, the important part is not just where the quote is sitting. It is why it is there and what condition needs to be satisfied before it moves.
A stronger workflow defines:
- what triggers review
- what type of review is required
- who owns each review
- what information must be present before review can start
- what decisions can be made
- what happens after each decision
For example, the process might work like this:
- The estimator prepares the quote.
- The system checks for predefined risk triggers.
- If no triggers apply, the quote can proceed through the standard send path.
- If triggers apply, the quote is routed for the required review type or types.
- The reviewer either approves, rejects, or sends it back with conditions.
- The quote record stores the decision and any required notes.
- Only approved quotes can move to sent status.
This sounds simple because it should be. The complexity should sit in the approval logic, not in people having to remember unwritten rules.
What information should be required before review
Review stages often become bottlenecks because reviewers receive half-complete quotes and have to chase missing context.
That is a design issue.
If a quote needs internal approval, the reviewer should receive the information needed to assess the risk, such as:
- scope summary
- pricing summary
- assumptions
- exclusions
- site or access notes
- drawings, photos or supporting documents where relevant
- contract terms if supplied by the customer
- explanation of what triggered review
If this information is inconsistent, the approval step will be inconsistent too.
The goal is not to drown reviewers in paperwork. It is to make sure the handover into review is complete enough for a decision to be made without unnecessary back-and-forth.
Protect operations from commitments made too early
One of the clearest benefits of a proper quote approval workflow is that it protects delivery teams from inheriting avoidable problems.
Operations should not be discovering after award that:
- the quote excluded critical delivery effort
- access constraints were never checked
- customer terms included obligations the team cannot realistically meet
- specialist work was priced like standard work
- the business accepted risk without explicitly deciding to do so
When these problems show up later, the business often absorbs them through rework, margin erosion, schedule pressure and internal frustration.
The approval step is where that exposure should be challenged.
This is especially important in businesses where sales, estimating and delivery are handled by different people or different teams. If the quote process does not force risk to become visible before the quote is sent, operations becomes the safety net for quoting decisions it did not make.
Keep the rules consistent, but allow human judgement
Predefined triggers are important, but they do not remove judgement.
Not every unusual job is a bad job. Sometimes the right decision is to proceed, provided the assumptions are tightened, the terms are clarified, or the pricing is adjusted.
The point of the workflow is not to block work unnecessarily. It is to make risk visible and decision-making repeatable.
That means:
- the system should consistently flag the same types of risk
- reviewers should still be able to apply judgement to the specific case
- exceptions should be recorded rather than handled informally
This balance matters. If the workflow is too loose, risky jobs slip through. If it is too rigid, it becomes administrative theatre and staff work around it.
Good approval design supports judgement. It does not replace it.
Where systems and automation actually help
This kind of workflow can be supported well by software, but only after the decision logic is clear.
Useful system behaviour might include:
- automatically flagging quotes that meet review criteria
- assigning technical and commercial review to different owners
- preventing send status until required approvals are complete
- prompting for missing information before review
- recording approval notes in the quote record
- surfacing approved assumptions for downstream handover if the job is won
What software should not do is add a generic approval step to every quote without distinguishing standard work from genuinely risky work.
That usually creates delay without improving judgement.
The value comes from making the right checks happen at the right time, for the right jobs.
What good looks like in practice
A well-designed quote approval workflow for high-risk or non-standard jobs usually has a few clear characteristics.
It is obvious which quotes require extra review and why.
The triggers are based on business rules, not personalities.
Technical and commercial review responsibilities are clear.
Approvers receive enough information to make a decision properly.
Approval outcomes are recorded inside the quote record, not buried in email threads or chat.
Conditions and assumptions remain visible for the person sending the quote and for the delivery team if the work is won.
Most importantly, the business is less likely to commit to work it does not fully understand.
That is the real purpose of quote approval in this context. Not delay for its own sake, and not bureaucracy to look controlled. The purpose is to stop unusual jobs being treated as routine when they are not.
If your quote process includes work with custom scope, delivery uncertainty or contract risk, it is worth mapping the approval logic properly before adding automation on top. Where that review path spans teams, handovers and multiple systems, 5M Consulting can help design a workflow that makes those decisions clearer and more consistent.