A missed-call text-back workflow should not mean "send the same sales text after every unanswered call." A responsible workflow confirms that a genuine inbound call was missed, applies approved eligibility and messaging rules, identifies the contractor, gives the caller a useful next step, handles replies and opt-outs correctly, and creates an accountable record for human follow-up.

The message is only one step. The complete system is:

inbound call -> classified call outcome -> eligibility decision -> approved message -> delivery state -> reply or no reply -> human owner -> documented outcome

This guide is an operational and technical checklist for Canadian contractors. It is not legal advice. Whether a particular text is a commercial electronic message, whether consent exists, which exceptions apply, and what identification or unsubscribe language is required depend on the actual facts. Have qualified counsel approve the messaging policy before activation.

Define the workflow's narrow job

The first message should help a recent caller continue the conversation they attempted to start. It should not quietly become a newsletter, promotion, review request, reactivation campaign, or year-long nurture sequence.

Write a one-sentence operating purpose:

Help an eligible recent inbound caller identify the business they reached, explain what they need, and receive the approved next step from an accountable person.

Then define exclusions. The missed-call workflow does not automatically authorize:

  • promotional campaigns;
  • unrelated service offers;
  • recurring marketing;
  • review requests;
  • customer reactivation;
  • mass broadcasts;
  • AI-generated estimates;
  • emergency dispatch promises; or
  • contact through additional channels.

Those activities need their own approved purpose, eligibility, consent, content, and suppression rules.

Classify the message before automating it

Canada's Anti-Spam Legislation applies to a commercial electronic message sent to an electronic address, and the CRTC confirms that SMS messages to mobile phones can fall within that framework. The CRTC describes three main requirements for sending a commercial electronic message: consent, identification information, and a working unsubscribe mechanism.

Not every electronic message is necessarily a commercial electronic message. The content, links, contact information, purpose, relationship, and surrounding facts matter. A practical workflow therefore needs an approved classification for each message type.

| Message class | Intended purpose | Approval question | | --- | --- | --- | | Missed-call acknowledgement | Respond to the caller's recent attempted contact | What facts support sending this response? | | Service conversation | Clarify the work, location, timing, or next operational step | Is the reply within the caller's request and approved channel? | | Appointment or quote follow-up | Continue an active requested process | What consent, identification, and record rules apply? | | Promotional message | Encourage a separate or future commercial activity | What valid consent and CASL controls authorize it? | | Review or reactivation request | Start a different post-service or dormant-customer workflow | Is this person eligible for that separately governed workflow? |

Do not let a CRM label such as "lead" decide the legal classification. Do not treat the presence of a phone number as proof of permission for every future text. The CRTC says the sender bears the onus of proving consent when relying on it for commercial electronic messages.

Before configuration, document:

  • the organization responsible for the message;
  • the countries and provinces or territories involved;
  • the number types and messaging providers used;
  • each message category and purpose;
  • the facts the organization relies on to send it;
  • required identification and contact information;
  • required unsubscribe wording and processing;
  • recordkeeping and retention;
  • third parties that send, route, store, or analyze the message;
  • escalation for complaints and legal questions; and
  • the person authorized to approve changes.

The CRTC's guidance on implied consent emphasizes that consent is fact-specific and that records should identify the electronic address, date, and method through which consent was received. Its SMS guidance says a commercial message's unsubscribe mechanism must be clear, readily performed, simple, quick, and easy.

A missed call on its own should not be treated as unlimited marketing consent. The approved policy should distinguish the immediate attempted-contact response from later promotional use and state when the conversation must stop or move to another authorized workflow.

Identify the exact call outcomes

Phone platforms can report several events that look like a missed call but should not all trigger the same action.

Build an allowlist of eligible outcomes:

  • a genuine inbound call;
  • to an approved public business number;
  • from a usable caller number;
  • not answered by a person or completed intake system;
  • with a final platform state the team has mapped and tested;
  • inside the allowed recency window;
  • not already handled through another route; and
  • not on a suppression list.

Review these outcomes separately:

| Call outcome | Text-back decision | | --- | --- | | Answered and connected | Do not send a missed-call acknowledgement | | Routed to voicemail | Decide whether voicemail counts as handled, missed, or eligible after a delay | | Caller hung up during the greeting | Apply an approved duration and outcome rule; do not guess intent | | Busy or agent rejected | Eligible only if policy treats it as an unhandled inbound call | | Provider or routing failure | Alert operations; do not hide an outage behind automation | | Caller ID unavailable | Do not attempt to manufacture or infer a destination | | Blocked or known abusive number | Suppress according to the approved abuse policy | | Repeated calls | Debounce so one caller does not receive a burst of identical messages | | Outbound call not answered | This is not an inbound missed-call event | | Transferred call abandoned | Confirm whether another employee already handled the caller |

Use the provider's final call status, not a temporary ringing event. If the platform sends multiple webhooks for one call, the workflow needs one durable call identifier and one eligible final transition.

Build an eligibility decision, not a single trigger

For each call, evaluate:

  1. Direction: Was it genuinely inbound?
  2. Destination: Did it reach an approved business number?
  3. Outcome: Was it actually unhandled under the policy?
  4. Caller address: Is there a valid reply-capable number?
  5. Suppression: Has the person opted out or been blocked?
  6. Duplication: Has this call or conversation already triggered a response?
  7. Recency: Is the response still connected to the attempted call?
  8. Local timing: Is immediate sending permitted under the approved rule?
  9. Conversation state: Is a human already replying or has another workflow taken ownership?
  10. Message authority: Is an approved message available for this situation?

If any required answer is unknown, route the event for review or fail closed. Automation should not fill missing authority with a guess.

Decide how timing works

The useful timing is prompt enough to be recognizable as a response, but timing is not simply "send instantly."

Account for:

  • the caller's known or inferred time zone;
  • quiet-hour and jurisdiction-specific rules;
  • the contractor's real response capacity;
  • whether voicemail is still being processed;
  • duplicate call events;
  • whether an employee answered through another device;
  • provider delays;
  • emergency and after-hours wording; and
  • the possibility that a reassigned number belongs to somebody else.

If an eligible call occurs during a restricted or unsupported period, define whether the system waits, suppresses, or sends a separately approved after-hours response. Do not promise a morning callback unless an accountable queue and staffing process support it.

The timestamp used for eligibility should come from a trusted server or provider event and include a time zone. Record the received time separately from the call time so delayed webhooks are visible.

Use a message contract

Every approved message template should have a field-level contract:

| Component | Requirement | | --- | --- | | Sender identity | Use the contractor's approved public identity | | Context | Accurately acknowledge the recent attempted call | | Purpose | Invite only the next information needed to handle that request | | Reply path | Explain how to continue through the monitored channel | | Urgent-work boundary | Avoid implying emergency monitoring or guaranteed dispatch | | Identification details | Include what the approved legal review requires | | Unsubscribe mechanism | Include and process it where the message class requires it | | Links | Use only approved HTTPS destinations, if a link is necessary | | Length and segments | Test the actual encoded message and provider behaviour | | Language | Match the approved audience and operational capability |

Avoid a long promotional block. Avoid shortened links that obscure the destination. Avoid asking for payment credentials, alarm codes, identity documents, medical details, or detailed access instructions over an ordinary text thread.

Do not insert service, city, availability, price, licence, or response-time claims from an unverified CRM field. Personalization should use approved data and remain safe when a field is empty or wrong.

Keep operational replies separate from marketing

A caller may reply with project information, ask to book, say they reached the wrong number, or request no further messages. The system should route those states without automatically adding the number to promotional audiences.

Maintain separate fields for:

  • operational conversation status;
  • channel preference;
  • legal or policy basis being relied on;
  • evidence source and timestamp;
  • marketing eligibility;
  • unsubscribe or suppression status;
  • template version;
  • last human action; and
  • next accountable step.

A person can be eligible for a response about an attempted call while remaining ineligible for promotional messaging. That distinction must survive CRM imports, list filters, workflow cloning, and platform migrations.

If express consent is collected for a separate marketing purpose, the choice should be clear and provable. The Office of the Privacy Commissioner says meaningful consent should emphasize what information is collected, with whom it is shared, and the nature, purpose, and consequences of the collection, use, or disclosure. Optional uses need genuine choices where required.

Make suppression global and immediate in the workflow

An opt-out is not merely a tag added for reporting. It is a control that must prevent future messages within its approved scope.

The workflow should:

  • recognize required opt-out keywords and variations supported by the provider;
  • preserve the original inbound reply;
  • record the time and channel;
  • apply the correct suppression scope;
  • stop scheduled or queued messages;
  • prevent new automations from re-enrolling the number;
  • synchronize suppression across relevant providers and CRM records;
  • confirm the result only through approved wording; and
  • alert operations when synchronization fails.

The CRTC says unsubscribe requests for commercial electronic messages must be acted on within the applicable period and recommends keeping up-to-date contact lists and accurate records. Design the automation to suppress immediately rather than using the maximum legal period as an operating target.

Do not make a person explain why they want messages to stop. Do not require login or a sales conversation to unsubscribe. A keyword parser should not reject a clear request merely because punctuation or capitalization differs.

Route replies into a real operating queue

The text-back succeeds only if replies reach someone who can act.

Use reply categories such as:

  • new service enquiry;
  • existing customer or active project;
  • scheduling request;
  • request for a call;
  • urgent or safety-related message;
  • wrong number;
  • opt-out;
  • unsupported media or attachment;
  • spam, harassment, or abuse; and
  • unclear reply requiring human review.

Automated classification can assist routing, but it should not invent project facts or send consequential advice without authority. The raw reply remains untrusted input. OWASP recommends validating data from external and third-party sources early in the workflow and applying both syntactic and business-context validation.

For every category, define:

  • queue or owner;
  • expected action;
  • escalation threshold;
  • allowed automated acknowledgement;
  • required human review;
  • data that may enter the CRM;
  • closure reason; and
  • evidence that the action completed.

Do not label the inbox "monitored 24/7" unless that is true. If urgent work cannot be handled through text, say so through approved language and provide the real alternative.

Handle emergency and safety messages conservatively

Contractors can receive messages about flooding, electrical hazards, gas odours, security issues, structural danger, or other urgent conditions. A generic marketing automation should not diagnose risk or promise emergency service.

The approved policy should state:

  • which urgent categories the business actually supports;
  • whether text is monitored outside business hours;
  • the alternative emergency or public-safety route;
  • what automation may say;
  • when human escalation occurs;
  • what information should not be requested by SMS; and
  • how failed escalation is detected.

Do not rely on keyword matching as the only safety control. People describe urgent situations in unpredictable language, and messages can be delayed.

Prevent duplicates and race conditions

One missed call can produce several events: ringing, forwarding, voicemail, no-answer, recording completion, and provider status updates. A person may also call twice while the first text is being queued.

Use:

  • a stable provider call identifier;
  • an idempotency record for the eligible trigger;
  • a conversation-level debounce window;
  • a check for recent human or automated messages;
  • atomic suppression and eligibility checks;
  • one final ownership state;
  • retry records that do not create new conversations; and
  • reconciliation for events received out of order.

The system should be able to answer:

  • Was a text authorized for this call?
  • Was one actually submitted?
  • Did the provider accept or reject it?
  • Was another copy prevented?
  • Did the person reply?
  • Who owns the conversation now?

Do not use the phone number alone as the idempotency key. The same person can make separate legitimate calls, and reassigned numbers can eventually represent different people.

Define the CRM data contract

Map the workflow before connecting it:

| Event data | CRM destination | Control | | --- | --- | --- | | Provider call identifier | Activity or conversation record | Unique and immutable | | Business number called | Source or routing field | Set from an approved allowlist | | Caller number | Contact channel | Normalize and protect | | Call outcome | Activity status | Map only tested provider values | | Eligibility decision | Workflow audit field | Store decision and reason code | | Message template version | Message record | Preserve exact approved version | | Consent or authority evidence | Compliance record | Keep source, date, method, and scope | | Delivery updates | Message status | Do not treat submission as delivery | | Reply category | Conversation state | Human-correctable | | Suppression state | Global messaging control | Enforced before every send | | Human owner | Task or opportunity owner | Never supplied by the caller |

Decide how contacts are matched. A phone-number match can connect an incoming call to an existing customer, but automatic merging can also attach the wrong history to a shared or reassigned number. Keep merge behaviour reviewable.

Distinguish provider acceptance from customer delivery

Messaging providers typically expose several states. The exact names vary, but the workflow should distinguish:

  • request created;
  • provider accepted;
  • queued;
  • sent to the carrier;
  • delivered where supported;
  • failed or undelivered;
  • inbound reply received; and
  • suppression or policy rejection.

A successful API response is not proof that the customer received or read the message. Store the provider message identifier and process later status events against the same record.

Retry only failures classified as temporary and safe to repeat. Use a bounded retry policy, retain idempotency, and stop when the conversation is suppressed or a human takes over. Permanent failures, invalid destinations, policy blocks, and opt-outs should not loop.

Create an alert when:

  • eligible call events stop arriving;
  • message failure rate changes materially;
  • the queue ages beyond the approved threshold;
  • suppression synchronization fails;
  • inbound replies have no owner;
  • a provider credential expires;
  • the public number routes incorrectly; or
  • delivery events cannot be reconciled.

Treat providers as part of the compliance boundary

A platform may send the message, but the business still needs to understand who is acting on whose behalf, which data is shared, where controls live, and how failures are handled.

Record:

  • account owner and billing owner;
  • sender number owner;
  • approved users and roles;
  • provider and subcontractor data paths;
  • template and workflow change permissions;
  • webhook authentication and rotation;
  • suppression ownership;
  • export and deletion options;
  • incident and outage contacts;
  • contract allocation of compliance responsibilities; and
  • how the business retrieves evidence after termination.

The CRTC recommends documented compliance programs, accurate records, policies, training, and third-party contracts. Do not assume a vendor's default workflow or compliance label proves that the business's actual configuration and messages are lawful.

Protect the phone number and message content

A phone number, call record, and message content can be personal information. The OPC's fair information principles call for identified purposes, limiting collection, limiting use and retention, accuracy, safeguards, and accountability.

Apply those ideas to the workflow:

  • collect only what the missed-call purpose needs;
  • do not copy full message content into every notification;
  • restrict conversation access by role;
  • encrypt data in transit and use supported provider safeguards;
  • set retention rules for call events, failed attempts, replies, and consent evidence;
  • remove access promptly when staff or vendors change;
  • review exports and backups;
  • avoid personal information in analytics tools; and
  • document how a privacy question or access request is handled.

Logs need care too. OWASP notes that logs can contain personal and sensitive information and recommends masking, sanitizing, hashing, encrypting, or excluding data where appropriate. An operational log can usually use internal event identifiers, reason codes, provider status, timestamps, and owner state without copying an entire customer message.

Provide another contact path

SMS is not usable or preferred by everyone. The caller may be using a landline, a shared phone, an assistive service, a number that cannot receive texts, or a plan where messages carry a cost.

The website and phone greeting should offer suitable alternatives such as:

  • a clearly labelled call-back path;
  • an accessible quote form;
  • a booking option;
  • an approved email address, if monitored; or
  • instructions for urgent situations.

Do not make texting the only way to correct information, opt out, or reach the business. The contractor quote-form checklist explains how to build an accessible alternate enquiry route with accountable CRM delivery.

Measure the workflow without calling every text a lead

Track states that help operations improve:

  • inbound calls by final outcome;
  • eligible and ineligible missed calls by reason;
  • duplicate triggers prevented;
  • messages submitted, accepted, delivered where supported, failed, and suppressed;
  • replies by operational category;
  • time from reply to human ownership;
  • unresolved conversations;
  • wrong-number reports;
  • opt-outs and complaints;
  • qualified enquiries;
  • booked next steps; and
  • provider or routing incidents.

Define a qualified enquiry separately from a sent message or reply. A wrong number, opt-out, spam response, or existing-customer service question may need handling without being a new sales opportunity.

Keep phone numbers and free-text replies out of general analytics events. Connect aggregate website and operational reporting through protected internal identifiers where justified.

Run a production acceptance test

Test on the actual configured numbers with approved test records. Cover the entire chain.

Call classification

  • [ ] Answered inbound call does not trigger a missed-call message.
  • [ ] Approved no-answer outcome follows the intended rule.
  • [ ] Voicemail behaviour matches the documented policy.
  • [ ] Outbound unanswered calls do not enter the inbound workflow.
  • [ ] Caller-ID-unavailable events fail safely.
  • [ ] Repeated and simultaneous events produce no duplicate burst.
  • [ ] Blocked and suppressed numbers remain suppressed.

Message and compliance controls

  • [ ] The correct business identity and approved purpose appear.
  • [ ] The template version is recorded.
  • [ ] Required identification and unsubscribe controls work.
  • [ ] Opt-out variations stop queued and future messages as intended.
  • [ ] Operational eligibility does not set marketing consent.
  • [ ] Links resolve to approved HTTPS destinations.
  • [ ] Empty or malformed personalization fields cannot create a misleading message.

Reply handling

  • [ ] Ordinary service replies reach the correct queue.
  • [ ] Wrong-number replies close and suppress correctly.
  • [ ] Urgent language follows the approved escalation path.
  • [ ] Attachments and unsupported media fail safely.
  • [ ] A human can take ownership without automation continuing over them.
  • [ ] Replies received after a delay attach to the correct conversation.

Reliability and security

  • [ ] Provider callbacks are authenticated using the supported method.
  • [ ] Unknown event types and malformed data are rejected or quarantined.
  • [ ] Temporary failure retries are bounded and idempotent.
  • [ ] Permanent failures create a visible operational state.
  • [ ] Provider credential failure alerts an owner.
  • [ ] Logs contain enough evidence without unnecessary message content.
  • [ ] CRM, provider, and suppression records reconcile.

Customer journey

  • [ ] The public phone number routes correctly.
  • [ ] Business hours and response expectations are accurate.
  • [ ] The website offers a usable non-SMS alternative.
  • [ ] The conversation has an accountable owner.
  • [ ] Test records are removed or clearly labelled after acceptance.

For every case, record the source call, expected outcome, actual message and status, CRM record, reply state, owner, timestamp, and defect reference. Redact personal information in tickets and screenshots.

Monitor the workflow after launch

Review the system after changes to:

  • phone numbers or routing;
  • business hours;
  • call forwarding or voicemail;
  • CRM pipelines and owners;
  • messaging provider accounts;
  • sender registration or configuration;
  • message templates;
  • consent and suppression rules;
  • services and operating areas;
  • staffing and escalation;
  • privacy or legal requirements; and
  • analytics or reporting.

Schedule a real end-to-end test rather than checking only whether the automation is enabled. A workflow can remain "active" while the number routes to the wrong destination, a credential has expired, replies are unassigned, or opt-outs no longer synchronize.

Make the text-back part of the service system

The broader contractor website design checklist connects calls, forms, proof, local discovery, measurement, and maintenance. The monthly website plans comparison helps assign ongoing responsibility for lead-flow tests, provider changes, and operational support.

Nexxen's website, automation, and SEO services for contractors include missed-call text-back in the managed website foundation, subject to approved phone, consent, messaging, and applicable-rule configuration.

The useful outcome is not the highest number of automated texts. It is a controlled recovery path where an eligible caller receives an accurate response, every reply has an owner, opt-outs are respected, failures are visible, and the business can prove what the system did.