At a glance
The decision this report helps you make
Where does a commercial request lose ownership, context or a required approval?
- Follow one real request across teams before choosing software.
- Give every stage an owner, required information and an acceptance check.
- Compare total handling effort and errors; faster entry alone is not a better process.
01 / Decision guide
Select one workflow with a clear boundary
A broad instruction to “fix the CRM” hides several different jobs. Choose a bounded path, such as an inbound equipment inquiry becoming a reviewed quotation, or an accepted maintenance proposal reaching the operational owner. Name the beginning, end, participating teams and the records that carry the work.
Collect a small permitted sample of recent requests: completed, delayed and abandoned. Include normal cases and exceptions rather than only the best examples. Redact unnecessary customer information. Compare what people say happens with the actual timestamps, emails, fields and attachments.
Look for repeated information requests, ambiguous stage names, unsupported promises and missing approvals. An issue that appears once may be unusual; a consistent pattern deserves further investigation. Keep the original process available while testing changes. Do not move live customer records or alter production systems during an exploratory review.
Put this to work
- Define the first and final event in plain language.
- Choose a sample that includes failed or delayed requests.
- Record the current owner and evidence for each transition.
02 / Decision guide
Separate customer experience from internal convenience
McKinsey’s 2026 global B2B survey highlights inconsistent information across teams and difficulty reaching knowledgeable people as supplier-switching concerns. That is external context, not proof that your specific CRM is causing lost sales.
Onyx interpretation: internal efficiency should be judged alongside the accuracy of the promise a customer receives. A fast form that omits suitability questions can create more work downstream. A tidy sales dashboard can still conceal a customer waiting for a named response.
Ask the customer-facing and operational teams to describe a successful handoff independently. Reconcile differences before automation. If Sales considers “sent” complete but Operations considers “accepted with required information” complete, the problem is a definition and ownership gap, not necessarily a software limitation.
Put this to work
- Record what the customer was told and which version was approved.
- Distinguish sending a request from receiving and accepting it.
- Keep technical suitability and safety decisions with authorized specialists.
- McKinsey & Company: The surprising economics of B2B growth
May 28, 2026. 2026 Global B2B Pulse; nearly 4,000 decision-makers across 13 countries. Not a proprietary Onyx survey.
03 / Decision guide
Define the minimum handoff record
Use one clear record or linked set of records. It should identify the opportunity, customer need, approved scope, missing information, technical reviewer where needed, agreed next action and current owner. Link to the approved quote or scope rather than copying numbers into several places without version control.
A required field is useful only when someone knows what belongs in it and who can verify it. Do not force a salesperson to invent technical values simply to move a stage. Allow an explicit Unknown or Needs review state with an owner and due decision.
| Record element | Why it matters | Acceptance check |
|---|---|---|
| Request and account reference | Avoid duplicate or misassigned work | The receiver can identify the correct customer and request |
| Approved scope/version | Preserve the actual commitment | The latest accepted document is linked |
| Constraints and open questions | Keep assumptions visible | Unknowns have owners; safety/technical gates are not bypassed |
| Owner and next action | Prevent an unowned queue | A named role accepts the handoff and next decision |
04 / Decision guide
Give transitions explicit acceptance rules
Write the workflow in verbs the team can observe: received, qualified for review, quote approved, quote delivered, customer decision recorded, handoff accepted. Use stages appropriate to your actual business rather than importing a generic sales funnel.
For each transition, identify the producer, receiver, required information and condition that prevents movement. Separate business approval from technical approval where both are necessary. A stage can be ready for commercial discussion while remaining blocked for installation, procurement or system release.
Use the worksheet to record acceptance evidence. A handoff is accepted when the intended receiver can find the agreed materials, understands the commitment and knows the unresolved decisions. A notification sent to a group inbox is not evidence that anyone accepted ownership.
Put this to work
- Document one normal path and the most consequential exceptions.
- Test unknown data, duplicate requests and a changed quote version.
- Confirm how the customer is updated when a required input is missing.
05 / Decision guide
Choose the lightest system that can hold the rules
First ask whether the current tool can reliably support the required fields, ownership and review states. A small team may be able to test the process in a controlled register before configuring a CRM. Higher volume or complex permissions may justify system configuration or integration. The tool follows the accepted process and operating constraints.
Write an integration boundary before implementation: permitted systems, access level, data fields, triggering event, allowed action and recovery method. Do not grant broad write access for a read-only reporting need. Customer communications, quote changes, production scheduling and deletion need explicit authority.
Keep a manual fallback and a visible exception queue. If a synchronization fails, the request must remain visible and recoverable. Repeated retries must not create duplicate tasks or send duplicate messages. Ask the system owner to demonstrate normal operation and recovery using test records before release.
Put this to work
- Test in an approved non-production environment or controlled fixture.
- Require independent review of important failure cases.
- Hand over configuration, ownership and a recovery instruction.
06 / Decision guide
Calculate capacity without calling it cash
Measure total time per completed request, including entry, checking, correction and follow-up. Compare similar work over a defined period and keep error rates alongside time. If the new process shifts work to a more expensive specialist or leaves more exceptions, apparent savings may disappear.
Illustrative arithmetic: 40 requests per week multiplied by 12 minutes of avoidable handling equals 480 minutes, or 8 hours per week. At a hypothetical loaded labor rate of $45 per hour, the capacity value is $360 per week. Four weeks at that volume would equal $1,440 of modeled capacity—not revenue, guaranteed savings or working capital.
Subtract new review effort, software, support and maintenance before comparing alternatives. Cash savings require an actual avoided cost. Revenue improvement requires completed customer outcomes and appropriate attribution. Use low, base and high assumptions when volumes or adoption are uncertain; do not quote a single return percentage without defensible inputs.
| Measure | Definition | Important caveat |
|---|---|---|
| Handling effort | Minutes across all roles per completed request | Include rework and review |
| Handoff acceptance | Accepted first-pass handoffs / handoffs reviewed | Define what counts as accepted |
| Elapsed time | Time between defined start and end events | Separate waiting from active work |
| Cash effect | Actual avoided expense less added expense | Capacity released is not automatically cash |
07 / Decision guide
Pilot, rehearse and decide
Choose a bounded pilot with named users and an agreed review period. Run recent redacted examples and clearly fictional test records through the proposed path. Include a missing specification, a changed scope, a duplicate request, an unavailable reviewer and a system failure. Fix critical defects before customer use.
Practice the handoff with both sender and receiver. Ask each person to explain when to proceed, when to ask a question and when to stop. Training completion is not enough; the receiving team must demonstrate that it can retrieve the correct version and act on the next decision.
At review, compare the baseline with actual pilot evidence. Continue only if the process is usable, ownership holds and consequential errors are controlled. Expand in a separate scope after acceptance. If the improvement is mostly a clearer responsibility or checklist, retain that result rather than forcing an automation project.
Put this to work
- Record defects and the exact retest result.
- Name the client owner for ongoing changes and exceptions.
- Decide continue, revise, expand or stop using agreed evidence.
Sources and method
Prepared by Onyx Advisory Group from the linked public sources and original decision analysis. Sources were reviewed on September 14, 2026. Onyx has not conducted a proprietary survey for this report. Suggested questions, worksheets and examples require validation in your operating context.
- McKinsey & Company: The surprising economics of B2B growth
May 28, 2026. 2026 Global B2B Pulse; nearly 4,000 decision-makers across 13 countries. Not a proprietary Onyx survey.