Use an SMS follow-up when the next step is brief, non-urgent, suitable for writing and permitted by your organisation’s channel rules—and when the recipient does not need a live discussion to complete it. Make another call when a real-time conversation is still necessary but no person-specific judgment is required. Transfer to a human during the current call when delay, sensitivity, ambiguity or authority makes human involvement necessary. If none of those conditions is met, create a clearly owned CRM task rather than forcing another contact attempt.
The recorded call outcome should drive this choice. “No answer”, “asked for details”, “needs an exception” and “urgent issue” are not interchangeable outcomes, so they should not trigger the same follow-up. A robust workflow first checks whether contact is allowed and safe, then chooses the least intrusive channel capable of completing the next step. It also defines a stop rule so an inconclusive interaction does not become an endless loop of calls and messages.
The SCOPE framework for choosing the next action
SCOPE is a five-gate framework for moving from a call outcome to one defensible next action. Apply the gates in order. A later gate cannot repair a failure at an earlier one.
1. State: what is known at the end of the call?
Record a specific outcome, not a vague status such as “follow up”. The useful state includes:
- what the contact requested or declined;
- whether identity or key details remain unresolved;
- whether the call connected, ended early or reached a clear conclusion;
- the promised next action, if any;
- urgency and any uncertainty that changes routing; and
- an owner and due point where further work is needed.
If the state is unclear, do not infer intent merely to keep automation moving. Route the record for review or create a clarification task.
2. Channel permission: may this workflow use SMS or place another call?
Check the organisation’s applicable consent, opt-out, privacy, calling-window and channel policies before selecting a channel. These checks are operational prerequisites, not a box to tick after a message has been sent. An SMS opt-out, a do-not-call instruction or an internal restriction should be represented as structured state that prevents the prohibited route.
Permission is channel-specific. Permission to conduct one call should not be treated automatically as permission for every later message or call. The workflow needs a policy-backed answer for the intended recipient, purpose, channel and timing. If it cannot produce one, assign human review without initiating contact.
3. Objective shape: can the next step be completed asynchronously?
SMS is a good fit for a compact, written next step: confirming a preference, providing a requested reference, asking one low-friction question or offering a clear route back. It is a poor fit when the answer is likely to branch repeatedly, requires nuanced explanation, contains sensitive detail, or depends on immediate back-and-forth.
Another call fits a bounded conversational objective that still needs synchronous exchange. Examples include collecting several related answers or resolving an interruption after the contact explicitly asked to resume later. The repeat call should have a defined purpose; “try again” is not enough.
4. Person required: does the next step need human judgment, authority or care?
Use a human transfer when the current connected call reaches an issue that should not wait and a suitable person is available under the organisation’s routing policy. Typical internal triggers can include an exception request, a complaint requiring discretion, material ambiguity, a sensitive situation, or a decision the AI workflow is not authorised to make.
A transfer is not the only form of human involvement. If no appropriate person is available, preserve the outcome and create an owned task with a due point and the safest approved contact route. Do not disguise a failed transfer as a completed handoff.
5. Exit rule: when must automation stop?
Every branch needs an end state. Define limits for attempts, elapsed time, repeated non-response, repeated ambiguity, channel refusal and failed transfers according to your policies and use case. At the limit, the workflow should stop contacting, close the loop where appropriate, or place the case into a named human queue. The exit rule prevents a routine follow-up from becoming unwanted persistence.
Post-call channel decision matrix
Use this matrix as a design worksheet rather than a universal rulebook. Replace each generic policy check with your approved, jurisdiction- and context-specific requirement.
| Recorded outcome state | Prerequisites | Choose SMS when… | Choose another call when… | Choose a human transfer when… | CRM task and owner | Stop or escalation rule |
|---|---|---|---|---|---|---|
| Connected; contact asks for a short written follow-up | Recipient and channel are confirmed; messaging is permitted; content is appropriate for SMS | The request can be fulfilled accurately in one compact message with a clear next step | The requested explanation cannot be handled reliably in a short written exchange | The request exposes an exception, sensitive issue or decision requiring a person | Log what was requested and the message status; assign review if delivery or meaning is uncertain | Do not add a call unless requested or required by the approved process |
| Connected; contact asks to continue later | A specific objective and acceptable contact route are recorded | Only a simple confirmation or scheduling choice is needed | Several related questions or a live discussion remain, and a later call was agreed | The unresolved issue already needs human authority or judgment | Assign the agreed next action, owner and due point | Stop if the contact withdraws or the approved attempt limit is reached |
| Call did not connect | The reason is distinguishable from a refusal or invalid destination; contact policy permits another attempt | A permitted, context-appropriate message can identify the reason for contact without exposing sensitive information | The objective genuinely requires speech and retry conditions are allowed | Not normally applicable until contact occurs; use review for risk or ambiguity | Record attempt outcome and next permitted action | Stop on refusal, restricted status, invalid destination or policy limit |
| Connected; one low-risk fact is missing | Identity and channel controls are satisfied; the missing field is necessary | One unambiguous answer can resolve the state | The answer is likely to need clarification or several dependent questions | The missing fact changes a sensitive or high-impact decision | Create a task only if no valid automated route remains | Stop rather than guess after ambiguous or conflicting responses |
| Connected; request falls outside workflow authority | Context is preserved and an approved destination exists | SMS only confirms the next process step; it does not attempt the unauthorised decision | Another automated call will not remove the authority gap | A suitable person must interpret, approve or resolve the request | Assign named queue or role, include reason and due point | Escalate immediately under policy; do not cycle back into automation |
| Transfer attempted but not completed | Transfer result is recorded accurately; callback route is approved | A brief confirmation can set an expectation without claiming a completed handoff | A scheduled call is the approved recovery route | A person still owns the unresolved case | Create a callback or review task with the failed-transfer outcome | Escalate missed ownership; never mark “transferred” when no person accepted |
| Contact refuses further contact or uses a recognised opt-out | The instruction is captured and propagated to relevant controls | Do not send promotional or follow-up SMS contrary to the instruction | Do not place another call contrary to the instruction | Human review only where required by policy, not as a way around the refusal | Record restriction and any necessary compliance review | Stop automated outreach |
| Urgent, sensitive or materially ambiguous issue | Applicable internal escalation route is known | SMS may only support an approved handoff or confirmation | Do not defer to a routine repeat call if delay creates unacceptable risk | Transfer or escalate to an appropriate person under the organisation’s protocol | Create a high-priority owned record if immediate transfer is unavailable | Stop ordinary automation and follow the escalation protocol |
The matrix separates channel selection from task ownership. An SMS can be the recipient-facing action while a CRM task asks an operator to review a reply. A human transfer can be the immediate action while a task records who must confirm completion. “Send message” and “case resolved” should never be treated as synonyms.
Example: appointment enquiry in a UK service team
This illustrative example is localised to a UK-based service team’s internal operating context. It does not claim a real customer result, and the team would still need to apply its own applicable communication and privacy rules.
An AI phone workflow answers an appointment enquiry. The caller explains what they need, confirms that the request is not urgent and asks for available appointment times by text because they cannot remain on the phone. The call outcome is recorded as requested written options, not merely interested.
The workflow applies SCOPE:
- State: the request and preferred next step are clear. The caller wants a bounded piece of information rather than advice.
- Channel permission: the workflow checks the team’s approved messaging conditions and the destination number. If that check fails, it does not send.
- Objective shape: sending approved appointment options is compact and asynchronous. A repeat call would add interruption without improving the task.
- Person required: no exception or judgment is present, so an immediate transfer is unnecessary. If the caller had requested an unavailable exception, the route would change to a person.
- Exit rule: the SMS asks the caller to select an option through the approved process. An unclear response creates a review task; a refusal or applicable stop signal ends automated follow-up.
The selected action is SMS, with the outcome and message status retained. The CRM task is conditional: it is created only if the reply is ambiguous, an option becomes unavailable, or the approved response window expires. If the caller had instead said, “I need you to make an exception today”, the correct route would be human judgment—not a longer SMS and not another automated call.
This worked example shows the central rule: choose a channel based on the unresolved work, not on the channel the workflow happens to have available.
Implementation steps
1. Define mutually exclusive call outcomes
Start with a small set of outcomes that describe what happened and what remains. Separate “requested SMS”, “callback agreed”, “human decision required”, “refused further contact”, “transfer completed” and “transfer failed”. Avoid overlapping labels that allow two contradictory routes.
2. Map each outcome to prerequisites
For each route, list the facts that must be present before it can run: destination confidence, relevant permission state, urgency, sensitivity, requested timing, transfer destination and ownership. Missing prerequisites should produce a hold or review state, not a guessed value.
3. Write one objective per follow-up
Specify what the next interaction must accomplish. “Confirm the requested reference” is testable; “nurture the contact” is not. A narrow objective makes it easier to decide whether SMS is sufficient or a conversation is necessary.
4. Configure person-required boundaries
List decisions the AI workflow may not make and contexts where a person must take over. Include the fallback when a transfer destination is unavailable. The fallback needs an owner, a due point and an accurate status.
5. Add task creation independently of contact action
Do not make CRM ownership depend solely on whether a call or SMS was attempted. Create tasks for unresolved ambiguity, failed transfers, missing prerequisites and replies requiring review. Close tasks only on a defined completion event.
6. Test transitions, not just messages
Use fictional test records to exercise each matrix row. Confirm that restricted states block contact, ambiguous outcomes do not select a channel, failed transfers remain unresolved, SMS replies can reach the correct owner, and stop rules prevent another attempt. Review both the recipient-facing action and the CRM state left behind.
7. Audit outcomes and refine definitions
Inspect records for contradictory states such as “opted out” plus “callback queued”, “transfer completed” plus “no accepting owner”, or “SMS sent” plus “no message purpose”. Correct the outcome model before tuning wording or adding more branches.
CallTurbo’s public platform information says calls, messages, outcomes, contact notes and follow-up tasks can remain in its CRM workspace, and that flows can route or transfer calls to agents and teams. Teams evaluating that supported path can explore CallTurbo’s platform and map SCOPE to their approved operating rules.
Pre-launch checklist
- Every call ends in one specific outcome state.
- SMS, repeat-call and transfer routes each have explicit prerequisites.
- Channel restrictions and refusal states block the relevant action.
- Urgent, sensitive, ambiguous and unauthorised decisions have a human route.
- A failed transfer remains open and receives an owner.
- Each follow-up has one bounded objective.
- Every unresolved branch creates a task or an intentional stop state.
- Attempt and elapsed-time limits are defined by the organisation’s policy.
- Test records cover no answer, interruption, refusal, ambiguity and unavailable staff.
- Records distinguish attempted, delivered, accepted and resolved actions where those states are available.
Limitations and trade-offs
This framework is operational guidance, not legal advice. SMS consent, opt-out handling, calling restrictions, privacy obligations and transfer procedures vary by jurisdiction, purpose and organisational context. Teams must obtain appropriate advice and encode their own approved rules; this article does not supply a universal permission model.
A recorded outcome can also be wrong or incomplete. Speech uncertainty, caller correction, shared numbers and interrupted calls can make an apparently simple SMS route inappropriate. High-impact workflows need conservative fallback behaviour and human review when the state cannot be established confidently.
SMS reduces the need for a live exchange only when the task is genuinely compact. Written follow-up can create fragmented conversations, delayed replies and context loss. Conversely, another call can be intrusive and inefficient when the recipient explicitly requested writing. A human transfer preserves judgment but depends on suitable availability and a reliable fallback. The framework makes those trade-offs visible; it does not eliminate them.
Finally, the verified public information used here establishes that CallTurbo supports calling, messaging, outcomes, human transfers, notes and follow-up tasks. It does not establish that SCOPE is a built-in automated decision engine, nor does this guide claim any particular performance result.
FAQ
Should an AI phone workflow always text after an unanswered call?
No. First distinguish no answer from refusal, an invalid destination or a restricted contact state. Then check whether messaging is permitted and context-appropriate. If the purpose requires a live exchange, an approved repeat call may fit better. If permission or state is uncertain, stop and create a review task.
When is another call better than SMS?
Choose another call when the remaining objective requires synchronous discussion, several dependent questions or clarification that would be cumbersome in short messages, provided another call is permitted. Record the objective and expected timing rather than scheduling a generic retry.
When should the workflow transfer to a human immediately?
Use an immediate transfer when a connected conversation reaches a person-required boundary and delay is not appropriate under the organisation’s protocol. Boundaries may include decisions outside workflow authority, material ambiguity, sensitive issues or exceptions. If no suitable person accepts, record a failed transfer and assign the fallback explicitly.
Can an SMS and a CRM task happen together?
Yes. They solve different problems. The SMS communicates with the recipient; the task assigns internal ownership. For example, a permitted message can request one missing answer while a task tells an operator to review an ambiguous reply.
What is the safest default when the call outcome is unclear?
Do not guess a channel. Preserve the available evidence, prevent contact actions that lack their prerequisites and route the record for review. The safest operational default is an explicit unresolved state, not a fabricated conclusion.
How should teams judge whether the framework is working?
Audit decision quality rather than assuming that more messages or calls are better. Check whether outcomes are specific, prerequisites are present, person-required cases reach an owner, failed transfers stay open, restrictions block contact and each case reaches a valid completion or stop state. Any performance metric beyond those process checks needs separately defined evidence and is not claimed here.