AIVA's SMS channel understands plain language. You can text "hey can you tell me if my order shipped yet" and it'll answer correctly. So the first time a customer texted a business's AIVA number with just the word "STATUS," in capital letters, nothing else, we treated it as an edge case to handle gracefully. Then we saw it again. And again. It wasn't an edge case. It was a habit.
Where the habit came from
Anyone who's used SMS banking in India already knows this pattern — text a keyword to check a balance, text a code to confirm a payment. It's fast, it's unambiguous, and you don't have to think about phrasing. People have been trained by their banks to talk to automated systems this way for years, and they bring that habit to every other business that texts them.
We were building a system that understood full sentences and treating short, capitalized keywords as something to merely tolerate. That was backwards. Customers were telling us, by how they actually typed, what the fast path should look like.
What we built
AIVA now recognizes a small set of explicit commands — STATUS, RESCHEDULE, REFUND, HELP — alongside everything it already understands in natural language. They're not a separate mode you have to opt into. Texting "STATUS" gets you an instant read on your current booking or request. "RESCHEDULE" opens the reschedule flow directly, instead of AIVA first having to infer that's what you want from a longer message. "REFUND" routes a request into the right process immediately. "HELP" lists what's available.
None of this replaces natural language — you can still text "can you move my Thursday appointment" and get exactly the same outcome as texting "RESCHEDULE." The command is a shortcut, not a requirement, and it's forgiving: "status please," "can I get a status update," and "STATUS" all land in the same place.
We didn't invent a command language. We noticed the one customers were already using and stopped making them route around it.
How a command actually gets recognized
The mechanism is simpler than the natural-language path on purpose. A message that matches one of the four keywords closely — regardless of case, trailing punctuation, or a stray word around it — gets treated as a direct request for that flow, skipping the longer reasoning process a more open-ended message needs. A message that doesn't match closely still goes through full understanding, the same as it always has. Commands aren't a separate product bolted on top of the SMS engine; they're a faster on-ramp into the same persistent conversation thread that already knows what's booked, what's pending, and what's still open for that customer.
That's also why a command still works no matter how long it's been since the last message. STATUS doesn't ask AIVA to look anything up fresh — it asks the engine to report back on the thread state it's already holding, the same state it would have used to answer a full sentence.
The edge cases worth thinking through
A keyword system sounds simple until you consider how people actually type. "What's the status of my order" contains the word "status" but isn't the command STATUS — it's a full sentence that happens to include it, and it gets handled through natural language, not treated as a bare keyword. The distinction is about the shape of the whole message, not just whether a keyword appears somewhere inside it.
Typos are the other obvious case — "RESCEDULE," "STATSU," a command sent with a stray space in the middle. The matching is forgiving enough to catch close misspellings of a four-word command set, because the cost of guessing wrong on a near-miss is low and the cost of forcing an exact match is a frustrated customer retyping a text. And a command that doesn't apply — REFUND texted by someone with no eligible booking or payment on file — doesn't get force-fit into a flow that doesn't make sense. AIVA checks the actual state behind the thread first and, if nothing matches, says so plainly instead of walking someone through steps that don't apply to them.
Why this is worth doing deliberately
There's a real reliability argument here too, not just a convenience one. Interpreting "STATUS" is a solved problem — it's an exact match, there's no ambiguity to resolve. Interpreting "can you check on the thing from before, I think it was for Friday but not sure" takes real reasoning, and reasoning has more places to go wrong than a keyword match does. For the handful of requests customers care about getting right every single time — where's my booking, I need to move it, I want my money back — giving them a deterministic path alongside the flexible one means the highest-stakes asks are also the ones least likely to be misread.
The other benefit is speed of trust. A customer who texts STATUS and gets an instant, correct answer learns something about the system in one exchange: it works the way they expect. That's worth more, long-term, than a beautifully-parsed sentence. It's the same reason replying to a reminder text with a plain "can we push this back an hour" works instead of bouncing the customer into a phone call — commands and natural language are two doors into the same reliable outcome, and reminders that customers can actually act on are what keeps a slot from turning into a silent no-show.
Same commands, no matter which channel opened the thread
Commands are an SMS-specific shorthand, but what they read from and write to isn't SMS-specific at all. STATUS doesn't check a text-only record — it checks the same underlying booking state that voice calls and web widget conversations also read and write, because every channel AIVA runs shares one conversation engine rather than keeping separate books per channel.
That's why a customer who booked over the phone can text STATUS an hour later and get an accurate answer, even though the booking itself never touched the SMS channel until that moment. The command is fast because it's a direct read on state that's already current, not because SMS has a shortcut the other channels lack. Build the shortcut on top of shared state, and it works everywhere that state is reachable. Build it on top of a channel-specific database instead, and it only ever works for customers who happened to stay on the one channel where they started — which, in practice, a lot of real customers don't.
Why we kept the list to four
It would have been easy to keep adding commands — CANCEL, CONFIRM, HOURS, PRICE — every time we noticed a new shorthand pattern show up in a handful of conversations. We've deliberately held off. A command list only helps if customers can remember it without checking, and a menu of fifteen keywords stops being a shortcut and starts being exactly the kind of rigid, press-1-for-this system we built AIVA to avoid in the first place. STATUS, RESCHEDULE, REFUND, and HELP earned their place because customers were already using them, unprompted, at real volume — not because we guessed they might be useful. If a fifth command shapes up the same way, with customers converging on it on their own, we'll build that one too. Until then, natural language already covers everything a longer command list would otherwise be trying to shortcut.
This same thread-aware design is what makes AIVA's confirmation and reminder texts two-way instead of one-off notifications, and it's part of why SMS reaches customers a chat widget structurally can't — no app, no login, just a thread and, when someone wants it, a shortcut into exactly what they need. You can see the whole channel, commands included, on the SMS platform page, or start a free trial and text your own number STATUS to see how fast the fast path actually is.