Sales pipeline design with OrelFlow
Explore WhatsApp sales pipeline automation with OrelFlow: customer journeys, connected records, team handoffs and practical launch steps.
By OrelFlow Editorial
Design a WhatsApp sales pipeline around customer evidence, clear ownership and safe automation. Includes stage rules, record examples, failure handling and an. With OrelFlow, sales stages can follow qualification, meeting requests and the next action your team owns. This guide explains how to connect that design to your OrelFlow solution and the work your customers need to complete.
Start with the decision the pipeline must support
A pipeline should answer three questions without requiring someone to reread the entire chat: What has the customer committed to? What must happen next? Who owns that action? If a stage cannot answer those questions, it is probably a task, label or marketing segment rather than a sales stage.
For example, “Interested” is ambiguous: a customer may have clicked an ad, asked for pricing or agreed to a call. Those actions carry different obligations. Instead, use observable evidence such as “customer requested a quote” or “customer accepted a meeting time.” Preserve the exact message or event reference behind the classification so a reviewer can challenge a mistaken move.
Keep deal stage separate from conversation state. A thread may be awaiting a customer reply while the deal remains in Proposal Sent. Similarly, a conversation assigned to an AI assistant does not mean an AI assistant owns the commercial relationship. These distinctions make work queues useful without distorting the pipeline.
Choose stages with explicit entry and exit criteria
A practical starting sequence is New Inquiry, Qualified, Meeting Agreed, Proposal Sent, Decision Pending and Closed. Adapt it to the sales process rather than adopting it unchanged. Some businesses need a separate discovery stage; others should omit meetings entirely. Document who can move a deal backward and why.
| Stage | Evidence required to enter | Exit trigger | Default owner action |
|---|---|---|---|
| New Inquiry | An inbound sales-related message tied to a contact and conversation | Customer supplies enough information for qualification, declines, or is routed elsewhere | Check identity and purpose; respond or request missing details |
| Qualified | Customer confirms relevant need and agreed qualification fields are recorded | Customer agrees to a defined next step | Confirm fit and propose that next step |
| Meeting Agreed | Customer accepts a specific proposed time | A booking is confirmed, cancelled, or cannot be completed | Verify calendar record and send a clear confirmation |
| Proposal Sent | Proposal delivery is recorded and linked to the opportunity | Customer acknowledges, asks for changes, accepts, or declines | Set a justified follow-up date and handle objections |
| Decision Pending | Customer indicates active consideration after receiving the proposal | Customer accepts, declines, or requests a materially different offer | Clarify decision process and obtain the next commitment |
| Closed | A human-approved outcome and reason are recorded | Reopen only under a documented rule | Complete handoff or record loss reason |
“Proposal Sent” is a seller action, so it is the exception to a customer-evidence-first stage model. Do not interpret it as customer engagement. If forecasts depend on acknowledgment, distinguish delivery from Decision Pending. Likewise, a proposed meeting time is not a confirmed booking. Where appointments matter, the calendar consistency guide explains why a calendar record and a customer-facing confirmation should agree.
Separate messaging, decision logic and the system of record
Design the workflow as four layers. The messaging layer receives a WhatsApp event and preserves its message identifier, sender, timestamp and conversation reference. The decision layer classifies the event and proposes a stage or task. The record layer validates that proposal against the current opportunity, owner and version. The action layer sends an approved reply, creates a task or requests human review.
That separation matters because arrival order is not necessarily business order. A delayed message or repeated delivery must not be treated as a new customer commitment. Store an event identifier for deduplication, compare event time with the evidence already accepted, and re-read the opportunity immediately before a write. Make changes conditional on a matching record version; if the version changed, reassess rather than forcing the old decision through.
The Meta WhatsApp Cloud API overview describes a developer interface for business messaging. It does not establish an OrelFlow integration or permission to send any particular message. Confirm account, messaging, consent and billing requirements against current Meta documentation and the intended operating setup.
Define entry rules, owner locks and safe automation boundaries
For each automated transition, write a rule in plain language before implementing it. For instance: “Move from New Inquiry to Qualified only when the customer’s latest relevant reply confirms the required need and the qualification fields have been reviewed.” Record the qualifying reply, rule version and time of decision. If the reply is uncertain, create a review task rather than manufacturing certainty.
Treat owner assignment as a separate decision from stage movement. A routing rule may assign an unowned new inquiry, but it should not replace a salesperson who has taken responsibility. An owner lock can be a simple policy: once a human claims the opportunity, automation may suggest reassignment but cannot apply it without an authorized decision. Specify exceptions for absence, queue overflow and manager intervention, with an audit reason for each override.
Avoid rules that advance a deal merely because a message was sent, a template ran or time passed. Those events can schedule a check, not prove customer intent. A customer saying “send details” may justify a task to prepare information; it does not necessarily mean a proposal was accepted. Likewise, “not now” might call for a consent-aware future follow-up plan, not an automatic win or loss.
Map inputs to a reviewable opportunity record
Decide which fields are authoritative before connecting systems. A phone number can help find a contact, but it may not uniquely identify a person or opportunity. Resolve possible duplicates and existing accounts before creating another card; the CRM routing and deduplication guide covers that decision in more detail.
| Input or decision | Record field or output | Validation rule |
|---|---|---|
| Incoming message ID and timestamp | Processed-event reference | Ignore an already processed ID; flag conflicting payloads |
| Sender and matched contact | Contact ID and match status | Review ambiguous matches before updating an opportunity |
| Customer’s stated request | Intent, evidence reference and confidence status | Keep the original message available for human review |
| Qualification answers | Named fields with provenance | Do not infer an answer from silence |
| Current stage and version | Proposed next stage and expected version | Reject an outdated proposal and recalculate |
| Human claim or assignment | Owner ID, lock status and audit reason | Never silently replace a claimed owner |
| Next commitment | Task owner, due time and expected customer action | Require a due time or an explicit reason for none |
An illustrative output record could contain `opportunity_id: O-1042`, `stage: Qualified`, `stage_evidence: message-782`, `owner_id: rep-07`, `owner_lock: human_claimed`, `next_action: propose discovery times`, and `next_action_due: 2027-04-14 15:00 local`. These are example fields and values, not OrelFlow schema or evidence of a live deployment. Store the applicable time zone and an audit trail alongside the record.
Illustrative scenario: from inquiry to a booked discussion
Illustrative example: A prospect messages a business asking whether it can support a particular service area. The workflow creates an inquiry only after checking for an existing contact and open opportunity. It links the original message, assigns an available queue owner under the agreed routing policy, and asks one necessary qualification question. It does not mark the deal Qualified because the first message alone does not establish fit.
The prospect replies with the required location and use case. A rule proposes Qualified, records that reply as evidence and creates a task for the owner to suggest a discussion. The owner claims the deal. An automated availability prompt might still be permitted, but a routing refresh cannot overwrite the owner claim.
The prospect then accepts Tuesday at 14:00. That response can support Meeting Agreed, but not a “booked” assertion until the appointment system confirms an event. Google’s Calendar event creation guide describes creating an event with a calendar identifier and start and end times, subject to appropriate authorization. This is an implementation reference, not evidence of an OrelFlow calendar integration. If event creation fails, leave a visible booking-pending task and ask a person to resolve the mismatch before promising a confirmed appointment.
Design failure paths before enabling automatic moves
Duplicate events should produce one business action. If the same customer reply is delivered twice, the second processing attempt should find its recorded event ID and stop; it must not create another card, advance another stage or send a second confirmation. If two different events race, a version check should accept one write and send the other for reassessment against the updated state.
Misclassification needs a reversible path. Allow an owner to correct the stage, attach the actual customer evidence and record why the automated interpretation failed. Corrections should inform rule review; they should not trigger a loop that immediately reapplies the rejected move. Mark low-confidence or contradictory replies for human handling, including cases where a customer expresses both interest and a condition that prevents progress.
An unavailable CRM or appointment service calls for a bounded retry and a visible failure queue. Preserve the incoming event, avoid reporting a successful stage change that was not saved, and do not issue a booking confirmation without a verified booking. If a contact asks to stop messages, route that request for prompt handling under the applicable messaging rules; a scheduled sales follow-up must not override it. Agree on who monitors failures outside business hours before launch.
Put operating controls around stale and ambiguous deals
Set a next-action policy by stage rather than an arbitrary universal timeout. A new inquiry may need prompt review; a proposal may reasonably wait for an agreed decision date. Record both the due time and why it was chosen. A stale-deal view should surface opportunities with no future action, overdue owner tasks or a stage whose evidence no longer fits—not silently move them to Closed.
Review a sample of stage changes each week, including automated moves, human reversals and deals with no owner. Give managers a short exception view: duplicate contact candidates, failed writes, owner conflicts, pending bookings and follow-ups without a recorded basis. Retain enough history to answer who changed a stage, what evidence they used and which rule ran. Define access and retention rules with the business and its advisers rather than assuming every participant should see every message.
Measure reliability and commercial usefulness separately
Establish definitions before comparing performance. Stage evidence coverage is the share of stage entries with an accessible supporting event or approved human reason. Owner stability is the share of claimed opportunities without an unauthorized owner change. Next-action coverage is the share of open opportunities with an accountable owner and either a future task or a documented exception.
Track stale-deal count by stage and by the agreed due-time policy, not simply by age. Correction rate is human-reversed automated stage moves divided by automated stage moves in the review period; inspect reasons rather than treating every correction as bad. Failed-write recovery time runs from a failed record update to successful reconciliation or explicit manual closure. For appointments, separately count accepted times that lack a verified booking record.
These measures test whether the pipeline is trustworthy. Conversion and revenue can be reviewed too, but they depend on sales conditions beyond stage automation. Do not promise an uplift from cleaner records without a baseline and a credible comparison.
Implementation acceptance checklist
Before rollout, ask the business owner, sales lead and technical owner to approve the following in a test environment:
- [ ] Every stage has a named entry rule, exit rule, evidence requirement and authorized manual override.
- [ ] Conversation state, appointment state and opportunity stage remain distinct; a sent message alone cannot demonstrate customer agreement.
- [ ] Contact matching finds a known contact and flags an ambiguous match rather than creating an unchecked duplicate.
- [ ] Replaying an event causes no second card, task, stage move or outbound confirmation.
- [ ] A late event cannot overwrite a newer stage decision; the conflict is logged for review.
- [ ] A human-claimed owner survives routing refreshes unless an authorized override is recorded.
- [ ] A failed CRM or calendar write leaves a visible exception with an accountable owner; the customer is not told an unverified booking succeeded.
- [ ] Test cases cover decline, silence, unclear intent, cancellation and a request to stop messages.
- [ ] Dashboards use agreed definitions for evidence coverage, next-action coverage, correction rate and failed-write recovery.
- [ ] Staff can inspect and correct a record without erasing the original event or creating an automation loop.
Run these tests with realistic sample conversations and agree on acceptable thresholds before any live rollout. The checklist is an acceptance design, not a statement of current product behavior.
Evaluate the OrelFlow fit against your operating model
Use OrelFlow’s pipeline page to frame the desired workflow, then bring a stage map, sample messages, ownership policy and list of existing systems to a demo discussion. Ask the team to demonstrate or confirm event handling, field mapping, human overrides, exception visibility and what happens when an external write fails. Check which integrations and messaging arrangements are available, who performs onboarding, and how pricing applies to the proposed scope.
The shop may be useful when exploring automation templates, but verify any relevant template’s contents, availability and suitability before purchasing or planning a deployment around it. A good evaluation ends with a documented pilot scope and acceptance criteria, not an assumption that a page description proves the complete workflow is ready.
FAQ
Should an AI classification automatically advance every qualified lead?
No. A classification can propose a move, but the rule should require the specific answers that define qualification, a linked customer event and a valid current record version. Ambiguous replies belong in a review queue. For higher-stakes transitions, such as a commitment affecting forecasts or staffing, require owner approval. This keeps automation useful for triage without turning an inferred intent into a customer promise.
What happens when a prospect has several WhatsApp conversations?
Decide whether they concern one active opportunity or separate purchases before merging them. Link each conversation to the relevant contact and opportunity, keep its message evidence identifiable, and show the owner what is already in progress. If the match is uncertain, hold the new inquiry for review instead of copying a stage or owner across records. A contact-level history is helpful, but it should not collapse distinct deals into one card.
When should an inactive opportunity be closed?
Close it under a documented policy, not merely because an automated follow-up timer expired. Consider the last customer commitment, the agreed decision date, outstanding staff tasks and any message asking not to be contacted. Require a reason such as explicit decline, duplicate opportunity or approved inactivity closure. Keep the history and define a controlled reopen path if the customer returns; otherwise, closure can hide work that still needs an owner.
Continue your implementation journey
Continue with CRM Lead Routing and Deduplication for Conversational Workflows. A practical design for normalizing phone numbers, detecting existing accounts, handling duplicate events, assigning owners and reconciling safe CRM writes. Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.
Continue with Real Estate Site Viewings: Agentic Qualification and Appointment Handoffs. A practical design for qualifying real estate viewing requests on WhatsApp without inventing property availability, promising unverified slots or losing the H Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.
Continue with Healthcare Booking Automation: Keep AI in the Administrative Workflow. A practical guide to healthcare appointment booking automation: define administrative boundaries, protect booking records, handle failures and measure a safe, Use its implementation checklist alongside this guide when mapping your OrelFlow workflow.
Build this journey around your business
Start your OrelFlow setup with one specific customer request. Bring the current conversation, the records the team checks and the action that should follow. Define what the assistant can answer, what a connected workflow can change and which decisions stay with your people. Sales stages can follow qualification, meeting requests and the next action your team owns.
Use the steps in this guide as acceptance criteria for your own configuration. Walk through a successful request, missing information, an unavailable connected system and a request that needs a person. Agree how your team will measure completion and review exceptions before expanding to another customer journey.
Explore the relevant OrelFlow workflow, browse ready-to-customize templates, or plan the setup with our team. Template purchases and any separately scoped setup work should match the actual requirements of your business.
Sources and further reading
- https://developers.facebook.com/docs/whatsapp/cloud-api/overview/
- https://developers.google.com/workspace/calendar/api/guides/create-events