For the complete documentation index, see llms.txt. This page is also available as Markdown.

Channel Program Readiness

Review program permission, channel integration, delivery evidence, and recurring operational responsibilities before launching patient outreach.

A working channel demonstrates that a particular integration can send or receive. Launching a patient outreach program also needs an approved purpose, audience, sender, consent process, content, and operating plan. Keep these reviews separate so that a successful demonstration does not become permission for a broader campaign.

Use this guide to produce a program review with named owners and evidence for the intended route. Channel Manager explains managed provisioning and public service bindings. The channel-specific pages and capability matrix define which controls and operations the deployment can use.

Review the Program and the Route Together

Record the sending organization, the organization it represents, intended recipients and geography, purpose, sample content, consent evidence, channel, and provider route. Distinguish clinical eligibility for the program from permission to contact that person through that route.

For each restriction or approval, retain its source, scope, owner, and review date. Identify whether it comes from applicable law, a provider policy, a contract, or a configured product control. A provider's rejection should not be described as a universal statutory ban; a legal review alone does not establish provider acceptance.

Cloud services provide delivery building blocks with their own requirements. For example, AWS End User Messaging SMS guidance addresses registration, consent, content, and country-specific restrictions. Selecting a cloud messaging service still leaves the program and its operating responsibilities to be resolved.

Review
Evidence to retain

Purpose and authority

Approved audience, intended action, sender relationship, and clinical or business review where required

Recipient permission

Consent source and wording, collection time, permitted purpose/channel, and current suppression state

Route readiness

Applicable registration, sender assignment, provider acceptance of the intended use, and regional availability

Content and data

Reviewed examples, personalization limits, allowed attachments, and downstream processing requirements

Operation

Contact timing, attempt limits, reply handling, human escalation, incident ownership, and a stop procedure

Existing SMS controls distinguish registration, customer consent evidence, a recorded opt-in message, suppression, and content checks. Do not treat one record as proof of all five. Other channels have different controls; review their own contracts.

For example, a team with an approved appointment-reminder program wants to add health-coaching outreach using the same sender. A successful test message verifies connectivity. It does not establish that the existing purpose, consent wording, or registration covers coaching. Review that change before expanding the program, and identify the control or operator that will hold messages outside the agreed scope.

Preserve the Difference Between Each Outcome

Milestone
What it establishes
What remains separate

Candidate selected

Source data matches the configured selection criteria

Current eligibility, permission, and route readiness

Action authorized

The applicable control permits this particular action

Whether execution or delivery succeeds

Provider accepts

The provider acknowledges a send request

Carrier/device delivery and recipient engagement

Delivery reported

A channel-specific receipt reports delivery

Reading, understanding, agreement, or a clinical outcome

Recipient responds

An inbound event arrives

Identity resolution, intent, and any requested action

Business outcome verified

The authoritative destination or agreed evidence confirms the intended result

Attribution, durability, and longer-term benefit

These are evidence distinctions, not one shared Concurrence status enum. Keep case, action, Channel Manager message or call IDs, and conversation references so operators can investigate a particular attempt. A missing callback or timeout leaves an unknown result; reconcile before repeating an action that may already have occurred. Use only the retry and deduplication guarantees documented for the selected path.

Treat Channel Changes as New Decisions

Multiple channels provide more possible routes, each subject to its own permissions and capabilities. When a route is unavailable, the workflow should hold, escalate, or use an explicitly approved alternative. A rejection or opt-out is not permission to try another sender or transport.

Review transport fallback as well as application routing. A provider can have different downgrade behavior from an agent's requested channel. If the program permits only a particular transport, verify that the selected provider path can enforce that restriction. Supported conversation switching also does not supply consent for the new channel. See Multi-Channel Orchestration and Outbound.

Budget for Software and Continuing Operation

Compare building or buying the same scope. The recurring work includes maintained integrations, authenticated callbacks, correlation, failure recovery, suppression handling, and operational visibility. It also includes sender and campaign reviews, provider escalations, policy changes, reputation issues, and incident response. Some work is software; some requires an accountable operator and an external decision.

Agree which responsibilities the Concurrence platform and managed operations cover, which belong to the customer, and which need implementation work. A consulting engagement, agent runtime, or transport API does not by itself cover that full scope. Conversely, a managed channel does not guarantee every program will be accepted or every message delivered.

Test the intended route with synthetic cases for rejection, suppression, expiry, duplicate events, uncertain delivery, and human escalation. Confirm which evidence the customer can inspect through supported APIs, managed support, or the agreed UI. Revisit the review when purpose, content, provider policy, or routing changes; track those dependencies separately from engineering effort in the evaluation packet.

For a provisioned SMS route, continue with Test a Managed SMS Workflow to verify routing, suppression, exposed delivery evidence, and receipt by a controlled test recipient.

Last updated

Was this helpful?