Overview
When a recipient receives an mConnect call and taps Decline on their phone, you might expect the call to end immediately. In many cases, however, the call is still connected and routed to the recipient's voicemail, where it may be picked up by the call target before the recipient realizes what happened.
This is expected behavior driven by how mobile carriers and devices handle declined calls, not an issue with the mConnect feature itself.
Why This Happens
When an mConnect call is placed and the recipient taps Decline, the device sends a signal to the carrier network to redirect the call rather than fully terminate it. Most carriers interpret this redirection as a handoff to the recipient's voicemail, so the call continues and connects to the recipient's voicemail greeting, even though the recipient manually declined it.
This behavior is especially common on iPhones, though it can occur on other devices as well, depending on the recipient's carrier, voicemail setup, and device settings.
Because this happens at the carrier and device level, it is outside of what the mConnect platform can directly control or override.
What This Means for Your Campaigns
If a recipient declines an mConnect call, the call may still be connected to the call target's line. Depending on timing, the target may answer, believing the recipient is on the line, even though the recipient declined and may not be aware that the call connected.
If your use case is sensitive to this (for example, calls that should never reach a target unless explicitly accepted), keep this carrier-level behavior in mind when communicating instructions to your audience or evaluating mConnect for time-sensitive call routing.
Related: How the "CALL" Keyword Works
"CALL" is a system-reserved keyword used to trigger mConnect calls in response to text messages, including opt-in flows and broadcasts configured for mConnect call activation. Because it's reserved, it can't be set as a custom keyword in opt-in path configuration.
When a recipient texts "CALL," the system triggers the mConnect associated with the most recent mConnect-enabled message that the recipient received. If you're running multiple mConnect setups, make sure each recipient's most recent mConnect message points to the correct mConnect before they reply "CALL."