Why sales and operations need one status path
Shared status from opportunity to fulfilled delivery means sales and operations use one agreed sequence of stages for each customer commitment, with a named owner for every stage and a clear rule for what moves an item forward. Leaders can then see where every deal or order sits without asking two teams and reconciling their answers. The governance work lies in agreeing the stages, the owners and the evidence each transition needs.
Most enterprises have two status systems that meet awkwardly in the middle. Sales tracks pipeline stages that end at won. Operations tracks jobs that start at scheduled or in progress. Between them sits a gap where a deal is signed but not yet set up, and nobody owns it. Customers who call during that gap get vague answers from both sides. Finance feels it too, because billing milestones often depend on these stages, especially customer acceptance.
A status set that runs across both teams
Keep the set short enough that people use it consistently. Each status belongs to one team, and the handoff between teams is a status in its own right.
- Opportunity: sales is pursuing; owned by sales
- Proposal agreed: terms accepted in principle; owned by sales
- Won, pending handover: signed, handover pack in progress; owned by sales
- Accepted by operations: delivery lead has reviewed the pack and confirmed work can proceed; owned by operations
- In delivery: work under way; owned by operations
- Delivered, awaiting acceptance: work complete, customer sign-off pending; owned by operations
- Fulfilled: customer has accepted; closed
Rules for moving an item between stages
The accepted by operations stage forces an explicit handoff and makes the time between signing and starting visible, instead of hiding it inside either team's stages.
Each transition needs an owner and evidence. Sales moves a deal to won, pending handover with a signed contract attached. Operations moves it to accepted only after the delivery lead confirms the handover pack is complete and the scope is deliverable. Delivered, awaiting acceptance needs a delivery record; fulfilled needs the customer's sign-off or the acceptance mechanism the contract describes.
Restrict who can change each status. If anyone can move anything, statuses drift toward what people hope rather than what has happened. A salesperson should not be able to mark a job delivered, and an operations coordinator should not be able to mark a deal won.
Write the definitions on one page both teams can open while updating records. Most status disputes come from two people reading the same stage name differently rather than from bad intent.
Side flags for holds and risks
Real work does not move in a straight line. Add a small number of flags that sit alongside the main stage rather than replacing it: on hold, at risk and disputed. Each flag needs a reason and an owner. A job can be in delivery and at risk at once, which tells leadership far more than a single ambiguous status.
Agree who can set and clear each flag. Operations usually sets at risk for delivery issues; sales sets it for commercial issues such as a customer threatening to cancel. Clearing a flag should require a short note on what changed. Do not let flags become permanent. A job marked at risk for months with nothing changing is either not at risk or not being managed, and the review should force a decision either way.
Reviewing the shared pipeline together
Hold a regular review where the sales manager and the operations manager look at items in the boundary stages: won but not yet accepted by operations, and delivered but not yet accepted by the customer. Work stalls most often here, and neither team feels full ownership.
Look at flagged items next, then at anything that has sat in one stage much longer than usual. Record decisions against the item. Over time the review should get shorter, as stage definitions settle and people trust that the statuses reflect reality.
Send leadership a short summary after each review: how many items sit in each stage, which boundary items have waited longest, and which flags were raised or cleared. Counts by stage show bottlenecks that individual updates hide.
Holding the status path in your systems
Fasttrade's BukuCRM covers pipeline, opportunities and handover to delivery, and BukuOP covers work tracking, status and exceptions. If you want one status path visible across sales and operations, we can help you define the stages and ownership rules, and scope how status should be exchanged between the two systems in conversation with both teams.
Frequently asked questions
Should sales and operations use the same system to share status?
Not necessarily. Both teams need the same stage definitions, and each stage needs one owner. Some companies achieve that in one system, others in two systems with an agreed exchange of status. Choose based on how each team works day to day, and agree the definitions before deciding how to connect anything.
Who decides when a delivery is fulfilled?
The customer, through whatever acceptance process the contract describes, recorded by operations. Operations should not mark work fulfilled simply because it considers the job finished. Keeping a separate delivered, awaiting acceptance stage makes the difference visible and helps finance know when billing milestones tied to acceptance have actually been triggered.
How many statuses should the shared path have?
As few as the teams can use consistently while still showing the handoffs. A short path with clear owners and transition rules beats a detailed one that people update carelessly. Use flags such as on hold or at risk for exceptions, rather than adding a new main stage every time an unusual case appears.
Next step
Explore BukuCRM or tell Fasttrade what your team needs.
These articles explain enterprise process design. Product availability and detailed scope are confirmed in conversation.