Library·SOP·Operations
Configure cadences, evaluate stage criteria against recorded evidence, track contact points and advance opportunities with an auditable decision.
Last reviewed: · Editorial review
Clarity, structure and references reviewed in this version. This is not a test in a live account.
Organize the activities for each sales stage in 6am, execute follow-up and move opportunities using verifiable criteria.
Use Sales cadences, Pipelines, Opportunities and Follow-up tasks. You must be a company member with permission to manage contacts. Overriding a stage transition rule requires the company administrator role.
This version creates manual activities. Choosing Call, Email or WhatsApp tells the team which channel to use; it does not send messages. Stage acceptance and contact points are optional controls described below. This workflow does not include automatic loss, a holiday calendar or continuous list synchronization.
Before configuring, define the business event that starts each stage, the outcome required to leave it, who owns the opportunity and which activities are appropriate. Completing tasks is an operational control; it does not by itself prove qualification or customer acceptance.
The preview changes with the time it is viewed. Each activity time must fall inside the window, before its end. Editing and saving creates a new version for future enrollments; existing executions keep their original schedule and instructions.
For an existing opportunity without an execution, open Opportunities → Start cadence and confirm. This uses the current stage configuration and preserves independent tasks. Restore an archived contact before starting a new execution.
Choose the path matching the actual source:
The same contact may have opportunities in different pipelines. Each keeps its own execution, owner and tasks. Pausing or closing one must not be used to control the other. The form/list intake task stays separate from cadence activities: review both to avoid redundant work when designing the process.
Overdue means pending beyond the scheduled time, or beyond the UTC date for older tasks without a time. Expired means the optional execution deadline has passed. The expiration routine runs every five minutes; even before its status is updated, an activity beyond its deadline cannot be completed through editing.
Advance only after the business outcome defined by the team has occurred. If a completion rule blocks advancement, review the activities. Do not mark an activity done merely to bypass a restriction.
When closing as Lost, enter a factual reason. It remains in history even if the opportunity is subsequently reopened.
For a legitimate exception that requires advancing or moving back without satisfying the rule, a company administrator can enter an Administrative exception reason when editing the opportunity. The explanation is recorded. This field does not allow invalid contacts, owners, stages or pipelines, or records from another company.
If the interface says the record changed, reload, check its current state and try again with correct data. Do not replay an old write or create another opportunity to avoid the conflict.
At the interval defined by leadership, review each pipeline:
Open History to inspect recent opportunity events, including changes, pause/resume and activity updates. The screen shows up to 100 recent events. Expiration can also be checked through task status and deadline; do not assume every system event has its own history entry.
For cleanup, close QA opportunities and review independent tasks first. Remove cadence links from every stage before archiving that cadence, including stages in archived pipelines. If the pipeline is already archived, temporarily reactivate it to remove its links, then archive it again. Preserve the history. Do not edit a definition expecting it to reschedule executions that already exist.
Changes to the opportunity, evidence, criteria, provider model/assessment contract or relevant state, and expiration of the validity period, make the evaluation outdated. Returning to a previously assessed stage does not restore the old pass after the opportunity changes. Reload and evaluate again. If the provider fails or returns an invalid result, advancement remains blocked where acceptance is required. A request can take up to 40 seconds. After a stuck request, wait two minutes, reload and retry. The daily company limit is 100 evaluation requests, including failed/no-evidence requests; repeatedly clicking is not a recovery procedure.
Existing stages start with this control disabled. Test accepted, rejected and missing-evidence examples with a QA contact before enabling a required gate for real work. Review false positives and false negatives with the sales owner; this SOP does not claim a measured accuracy rate.
Set Points on advance or win (0–1000) and Points on loss (-1000–0) on each stage. A manual advance or win records success points for the source stage; a loss records its loss points. The same opportunity/stage/outcome counts only once, so reopening and repeating it does not farm points. A later different outcome may add a separate delta.
Contact score is the accumulated integer across that contact's opportunities, including different pipelines. It can be negative and is not the 0–100 acceptance score. A contact merge preserves the ledger and associates the total with the surviving contact. Scores do not automatically move an opportunity. Historical stages cannot be deleted while evaluations or points reference them.
Authorized integrations can record evidence, explicitly request acceptance, read evaluation history and read contact points through the tenant-scoped sales API. The technical team must provision a dedicated token with the necessary ability and current company permission; the public-library download token is not accepted. Requests use the current opportunity version and an idempotency key. Retrying an uncertain request uses the same key and payload; a deliberate new evaluation uses a new key. API evaluation also never advances a stage automatically.
Use clearly identified QA opportunities and an internal test contact. Do not send messages to customers. Record the result of each check rather than assuming that configuring a field proves the behavior.
| Check | Expected result |
|---|---|
| Send list A to pipeline A and list B to pipeline B | Separate opportunities, each with its chosen stage, owner, initial task and cadence activities. |
| Preview another send to the same destination | Existing contacts are skipped, including closed opportunities. No duplicate task should be created. |
| Pause only A, then resume A | B remains unchanged. A’s pending cadence schedule shifts according to the saved window; independent task dates are preserved. |
| Advance with required cadence incomplete | The opportunity stays in the source stage; no success points are added. |
| Complete cadence but omit a required valid acceptance | Advancement remains blocked. Record evidence and explicitly evaluate before retrying. |
| Advance to a stage with the same cadence | Existing progress and task identities are preserved. |
| Advance to a different cadence | The old execution ends and the destination cadence starts; completed work remains in history. |
| Return, evaluate again and repeat a successful advance | The same opportunity/source-stage/success combination adds no duplicate points. |
| Close as won or lost | Loss requires a reason. Pending cadence activities are cancelled; completed activities and independent tasks are preserved. |
For bilingual acceptance, include direct positive statements, missing or ambiguous evidence and explicit contradictions in EN and PT-BR. Keep the QA identifier in the record/source reference and distinguish test statements from genuine customer evidence. Do not rewrite real customer facts to obtain a pass. These checks exercise the workflow; they do not establish accuracy for real sales data.
After closing the test opportunities, resolve remaining independent tasks, remove stage/cadence links, archive the QA configuration and retain its audit history.
Use a QA contact with two opportunities in different pipelines: verify the schedule, pause one, confirm the other stays independent, complete an activity, test an advancement rule and inspect history. Close QA opportunities with a reason and review independent tasks. Only then apply the configuration to real entries.
