Tap-to-confirm cards vs SMS fallback for voice intake
Side by side
| On-screen card | SMS fallback | |
|---|---|---|
| Needs a phone number first | No | Yes |
| Stays in the call flow | Yes, same session | No, caller switches to messages |
| Latency | Instant render | Carrier round-trip |
| Works with no screen (PSTN) | No | Yes |
Why on-screen wins for web sessions
SMS was the original workaround because it was the only second channel a phone agent had. It carries three costs: you need a valid mobile number before you can send anything, the caller leaves the conversation to open their messages, and the message rides a carrier round-trip that can lag or drop. For a web session, none of that is necessary.
An on-screen card renders in the tab the caller is already in. They read the value, tap Confirm, and stay in the call. It also covers fields SMS handles awkwardly, such as choosing from a list or confirming a written-out date.
Use both, in order
Powsoo renders a card when a web session exists and falls back to SMS when it does not. You wire the agent once and it handles web and phone callers without branching logic. See the data-capture guide for the full picture, or what a visual layer is for the concept.
Frequently asked questions
Is SMS confirmation worse than an on-screen card?
For web sessions, yes. SMS needs a valid phone number first, sends the caller out of the call to their messages app, and adds a carrier round-trip that can lag or fail. An on-screen card confirms in the same session with a single tap.
When is SMS the right choice?
On pure phone calls with no browser. If the caller reached the agent over PSTN and there is no web session to render into, an SMS one-tap link is the way to get a confirmed value.
Can I use both?
Yes. Powsoo renders on-screen cards when a web session exists and falls back to SMS when it does not, so the same agent handles web and phone callers without separate logic.