> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/channels/program-readiness.md). # 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](https://docs.concurrence.com/developer-guide/platform-api/conversations/channel-manager) explains managed provisioning and public service bindings. The channel-specific pages and [capability matrix](/platform-overview/capability-availability.md) 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](https://docs.aws.amazon.com/sms-voice/latest/userguide/best-practices.html) 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](/channels/sms.md#consent-and-registration) 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](/channels/conversations.md#multi-channel-orchestration) and [Outbound](/channels/outbound.md). ## 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](/platform-overview/evaluation-packet.md). For a provisioned SMS route, continue with [Test a Managed SMS Workflow](https://docs.concurrence.com/developer-guide/guides/test-managed-sms) to verify routing, suppression, exposed delivery evidence, and receipt by a controlled test recipient. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.concurrence.com/channels/program-readiness.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.