Quote turnaround: three days to under four hours

The challenge

Regional sales teams were building quotes by hand, then routing discount approvals through email and Slack threads that had no record in Salesforce. Every quote sat in someone's inbox until they got to it, pricing errors reached customers because nothing validated discount thresholds against approval level, and sales leadership had no visibility into where a quote was stuck or why. The underlying problem was structural rather than a matter of people being slow. Freight and logistics pricing is layered: a base rate depends on lane, mode and service level, then accessorial charges, fuel adjustments and volume commitments modify it, and each region had developed its own spreadsheet to handle that logic. Those spreadsheets drifted apart over time, so the same lane could be quoted differently depending on which office built the quote. Nobody was acting in bad faith; the rules simply lived in individual files and in individual heads instead of in a system that enforced them. Approvals made it worse. The company had a real approval policy, with deeper discounts requiring more senior sign-off, but the policy was enforced by convention. A rep decided for themselves whether a discount needed approval, asked for it in whatever channel was convenient, and waited. The approver often lacked the context to decide quickly, because the deal details sat in a spreadsheet the approver had never seen, so the first response was frequently a question rather than a decision. Each round of questions added hours or days, and none of it was recorded on the opportunity. This pattern is common in B2B quoting projects, and it tends to produce three failure modes at once: slow turnaround that costs deals to faster competitors, inconsistent pricing that erodes margin quietly, and an audit gap where nobody can reconstruct why a given discount was granted. Fixing only one of them, for example adding a faster approval channel without validating pricing, usually just moves the problem. The engagement was scoped to address all three together. There is a further reason these projects are harder than they appear from the outside: the people involved are usually good at their jobs and are working around a broken process, not failing at it. A rep who builds a quote in a personal spreadsheet is compensating for a system that does not handle their pricing. An approver who replies late is handling a queue that is invisible and unprioritized. Treating the situation as a training issue, or as a matter of telling people to follow the process more carefully, ignores that the process itself has no place for the information they need. The starting point for the work was therefore to understand why each workaround existed, since every workaround encodes a real requirement that the new system would have to meet or the team would simply rebuild the workaround. It also meant being realistic about risk. Replacing a quoting process touches revenue directly: if the new system is slower or more restrictive than the old one, reps will find ways around it, and if it prices incorrectly, the errors reach customers at scale. The project plan accordingly gave as much weight to testing, exception handling and adoption as to configuration, because those are the areas where quoting implementations most often fail after a technically successful build.

The approach

1. 01

   Discovery

   Audited the existing quote-to-approval path end to end — every hand-off, every spreadsheet, every place a quote could stall — and mapped it against the actual approval authority each role was supposed to have. The audit deliberately compared the written policy to what people actually did, because the gap between the two is where most of the risk sits. It also identified which spreadsheet rules were genuine business logic worth encoding and which were historical workarounds that could be retired.

2. 02

   Pricing model agreement

   Before any configuration, sales, finance and operations agreed in writing on how a price is built: which factors drive the base rate, which accessorials apply when, and what discount ranges are legitimate for which deal types. This step is unglamorous and frequently skipped, and skipping it is the most common reason a CPQ build reproduces the old inconsistency in a more expensive tool. Configuration can only enforce rules that someone has actually decided.

3. 03

   CPQ and pricing rules

   Rebuilt the product catalog, price rules and discount schedules in Salesforce CPQ so a rep could only generate a quote the system already knew was within their authority to send. Products were structured so that common service combinations were selectable as bundles, which reduces the number of manual choices a rep makes and therefore the number of places an error can enter. Price rules were built to be readable, so a finance owner could later change a rate without needing a developer.

4. 04

   Approval matrix design

   Translated the written approval policy into an explicit matrix: which discount depth and deal size combinations require which approver, and who covers when that approver is unavailable. Building the matrix first, as a plain table reviewed by the people who would live with it, meant disagreements about authority surfaced in a meeting rather than after go-live. It also forced a decision on delegation, which is where approval workflows most often stall in practice.

5. 05

   Approval automation

   Replaced the email/Slack approval chain with automated routing based on discount depth and deal size, so a quote above threshold lands directly in the right approver's queue instead of a shared inbox. The approval request carries the quote details, margin context and customer history with it, so the approver can decide from the request itself rather than asking follow-up questions. Approve, reject and request-changes outcomes are all recorded against the opportunity, which creates the audit trail that did not previously exist.

6. 06

   Escalation and reminders

   Added timed reminders and escalation paths so an approval sitting untouched surfaces to the approver's backup or manager instead of waiting silently. The goal is that no quote can stall invisibly. Escalation rules were tuned with the approvers themselves so that reminders felt useful rather than noisy, since an approval process people learn to ignore is no better than the email chain it replaced.

7. 07

   Reporting on quote flow

   Built views showing where quotes sit, how long each stage takes and which approvals are pending, so sales leadership could see bottlenecks as they formed. Making the process measurable is what turns a one-time fix into something a team can keep improving, and it gives managers a factual basis for coaching instead of anecdotes.

8. 08

   Product and rate catalog cleanup

   Catalog quality sets the ceiling for everything CPQ can do. The existing catalog had grown by accumulation: near-duplicate services, retired offerings still selectable, and naming that differed between regions for the same thing. Each duplicate is a chance for a rep to pick the wrong line, and each inconsistent name makes reporting unreliable. The cleanup grouped services into a consistent structure, retired what was no longer sold, and agreed one naming convention. This is slow and unglamorous work, but a CPQ configured on top of a messy catalog simply automates the mess, and the price rules built afterward are simpler and more reliable when the products beneath them are well defined.

9. 09

   Customer-facing quote output

   A quote is also a document the customer reads and signs, so the output was treated as part of the system rather than an afterthought. The generated quote was designed to show the terms, service scope and validity period clearly, and to be produced from the same data the approval used, so the number a customer sees is always the number that was approved. Producing the document from the record removes a subtle risk of the old process, where a rep could edit a figure in a document after approval and send something nobody had actually signed off.

10. 10

    Downstream handoff to order and billing

    Winning a quote is not the end of the process; the accepted terms have to reach whoever books the shipment and whoever invoices it. The design considered what happens after acceptance so that pricing agreed in the quote is what operations and billing see, and not something re-keyed by hand. Re-keying is where pricing disagreements are born, because a small transcription difference turns into an invoice dispute weeks later. Even where a full integration was not warranted, defining the handoff fields and the moment of handoff reduced the risk of the accepted price changing on its way downstream.

11. 11

    Role-specific training

    Reps, approvers, sales ops and finance each interact with the system differently, so a single training session serves none of them well. Materials were split by role: reps learned to build and submit quotes, approvers learned to review a request and decide from it, and sales ops and finance learned how to maintain rules and read the reports. Short, task-focused walkthroughs using real quote scenarios proved more useful than feature tours, and reference guides were kept brief so that people would actually consult them when something came up.

12. 12

    Metrics agreed before the build

    The team agreed at the outset how quote turnaround would be measured: from which event to which event, and which quotes were included. Settling this before configuration meant the eventual before-and-after comparison rested on a consistent definition instead of a figure argued about afterward. It also shaped the build, since the system needs to capture timestamps at the right moments to measure anything at all. Deciding what to measure late in a project usually means the data was never collected.

13. 13

    Handling exceptions and non-standard quotes

    Every quoting system meets deals that do not fit the standard catalog: a custom lane, a one-off accessorial, a customer with negotiated terms. If the system has no path for these, reps abandon it and go back to spreadsheets for anything unusual, which quietly recreates the original problem in the highest-value deals. The design therefore included a defined exception route: a rep can request a non-standard line, it is routed to a named owner for pricing, and the result is recorded on the quote. Exceptions stay visible and reviewable instead of disappearing into side channels. The team also tracked which exceptions recurred, because a repeated exception is a signal that the catalog is missing a product and should be extended.

14. 14

    Permission and security model

    Quoting touches sensitive information: margin, cost basis and customer-specific pricing. Profiles and permission sets were designed so that reps see what they need to build a compliant quote without exposing cost or margin data they have no reason to hold. Approvers and finance received broader visibility. Doing this deliberately at the start avoids the common alternative, where access is granted broadly to make the project go live and then never narrowed. It also means the approval matrix and the permission model agree with each other, which prevents a situation where the system allows someone to do something the policy forbids.

15. 15

    Sandbox testing and user acceptance

    Before production, the team built test scenarios from real historical quotes, including the awkward ones, and ran them through the sandbox to confirm the price rules produced the expected result and the approvals routed to the right people. Testing against real cases rather than tidy examples is what surfaces the rule interactions that break in practice, such as a discount and an accessorial applying together in a way nobody anticipated. Sales ops leads then ran their own acceptance tests, which served a second purpose: the people who would support the system afterward learned it by using it, not by watching a demonstration.

16. 16

    Change management and adoption

    Most quoting tools that fail do so through low adoption rather than technical fault. The rollout addressed this directly by explaining to reps what the change gave them, such as faster approvals and fewer disputes over pricing, instead of presenting it only as a compliance control. Regional leads were asked for feedback during the pilot and some of it changed the design, which signalled that the system was being built with the team and not imposed on it. Reps who find a tool makes their day easier will use it without enforcement, whereas reps who see only added steps will find ways around it.

17. 17

    Ownership and governance after go-live

    A pricing system is only as current as its owner keeps it. Before handover, the team named who owns price rules, who owns the approval matrix and how change requests are raised and reviewed. Without this, rates go stale, new products are added inconsistently and the approval policy drifts away from what the system enforces. A light governance routine, including a regular review of pricing rules and approval thresholds against current business policy, was documented so that the improvement persists as people change roles.

18. 18

    Approver workload and delegation

    Routing approvals to the right person only works if that person can actually respond. The design looked at how many requests each approver would realistically receive and adjusted thresholds so that routine, low-risk discounts were handled at a lower level and only genuinely material ones reached senior staff. Delegation rules covered holidays and absences, so a request never waited on someone who was away. Overloading a single senior approver simply relocates the bottleneck, so the matrix was checked for balance as well as for correctness.

19. 19

    Post-launch tuning

    The first weeks after cutover were treated as a tuning period, not a finish line. The team watched where quotes still stalled, which rules generated unnecessary approvals and where reps were confused, then adjusted thresholds and screens accordingly. Some early rules turned out to be stricter than the policy intended, and loosening them promptly kept the team supportive. Treating go-live as the start of measurement is what separates a system that gradually improves from one that is quietly abandoned.

20. 20

    Migration and rollout

    Migrated historical quote and pricing data into the new structure, staged through a sandbox, then trained regional sales ops leads before cutting production over. Rollout followed a champion model: regional leads learned the system first and supported their own teams, which builds trust faster than a central team announcing a change. The old spreadsheets were retired on a clear date instead of being left available, because a parallel process guarantees people keep using the familiar one.

The result

With approvals routed automatically instead of chased over email, quote turnaround dropped from an average of three days to under four hours. Reps stopped losing track of where a quote was stuck, and pricing that fell outside a rep's authority got caught by the system before it ever reached a customer. The headline figure is the visible part of the improvement. The mechanism behind it is more useful to understand, because it explains what a team should expect to change in a similar project. Most of the original three days was not work; it was waiting. A quote spent the majority of its life sitting in an inbox, waiting for someone to notice it, waiting for a question to be answered, or waiting for an approver to find the context they needed. Routing the request directly to the right person, with the deal information attached, removed the waiting, and the approval decision itself was always quick once the approver had what they needed. Two secondary effects mattered as much. First, pricing consistency improved because the rules were enforced at the moment a quote was built, not checked afterward, so the same lane was priced the same way regardless of which office quoted it. Second, leadership gained something they never had: a record. Every approval, rejection and change request was attached to the opportunity, so it became possible to see which discount levels were being requested, how often, and by whom. That visibility turns pricing from a series of individual judgment calls into a policy the business can review and adjust deliberately. It is worth being candid about what a project like this does not do. It does not make a poorly priced product profitable, and it does not remove the need for sales judgment on complex deals. Genuinely unusual quotes still need a human conversation, and the approval matrix has to be reviewed periodically as the business changes, otherwise the system faithfully enforces yesterday's rules. The value is in removing routine friction so that scarce senior attention goes to the deals that actually need it. The main lesson from this pattern is that speed came from agreeing the rules first and encoding them second; the software was the smaller part of the work. For teams considering a similar project, a few practical observations follow from how this one unfolded. The most valuable early activity was the audit of what people actually did, since it revealed both the real bottlenecks and the informal rules worth preserving. The most frequently underestimated activity was exception handling, because unusual deals are where a new system is judged. And the most reliable predictor of lasting success was ownership: a named person responsible for pricing rules and approval thresholds after handover. Where those three were handled well, the system stayed in use and stayed accurate. Where they were skipped, the usual outcome in projects of this kind is a technically correct system that the team gradually stops trusting. It is also worth separating what changed from what stayed the same. The pricing itself was not changed by the project; the same rates and the same discount policy applied before and after. What changed was where they lived and how they were enforced. That distinction matters when setting expectations internally, because leadership sometimes hopes that a CPQ project will improve margin on its own. In practice it protects margin by preventing unintended discounting and by making the discounts that are granted deliberate and traceable, which is a different and more modest claim, and a more honest one. The gain is control and speed, delivered by removing the waiting and the ambiguity around the rules the business already had.

Delivered within aibrevo's typical mid-market Salesforce timeline — see the Salesforce implementation page for the full range.