Give the agent a channel contract before adding fallback

Browse practical guides →

Treat fallback as an observable state change with a documented policy, not an invisible promise that every message will arrive.

Describe the behavior you need

List the channels you allow, the sender identity each uses and the features the application depends on. Typing indicators, read receipts, groups and media should each have a supported, unsupported or unconfirmed value. Apple’s channel overview is useful background; the vendor’s integration defines what your application receives.

Decide what the agent says when a feature is unavailable. It should not claim that a customer read a message because a different channel sometimes supplies read receipts.

Choose the owner of the fallback decision

Ask whether the provider selects the channel or your application requests it. Record which event reports the actual outcome. Then decide whether a change of sender, format or cost requires the workflow to pause for a person.

Avoid sending a second message simply because the first is taking longer than expected. Reconcile the first attempt using the provider’s documented status before choosing another channel.

Make channel changes visible in the pilot

With consenting test contacts, inspect the channel and identity at the recipient and in your event record. Include an unsupported feature and a delayed status. Check that the operator can understand the result without reading raw payloads.

Keep the observed behavior beside the provider’s written contract. If the two disagree, leave the case unresolved until the provider explains it rather than building an agent assumption on a single successful demo.