Giving admins a way to unlock SMS-restricted users
SMS restrictions are a blunt but necessary tool for keeping messaging trustworthy. The new Locked SMS admin panel gives your team a direct way to review and lift those restrictions when it makes sense.
Every messaging platform eventually grows a set of guardrails: rate limits, abuse heuristics, hard blocks. They keep the system healthy, but they also produce a steady trickle of legitimate users who get caught in the net — a sales rep who fired off too many texts before a demo, a support agent who tripped a spam threshold on a Monday morning. Until now, unwinding those cases meant a database ticket. That was fine when it was rare. It stopped being fine.
Why a dedicated surface
We considered folding SMS unlocks into the general user detail page, but restrictions have their own review workflow — you want to see who is locked, decide whether to unlock, and move on. Mixing that into a profile view buries the queue. A purpose-built admin panel lets an operator open one page, triage the list, and act. The new Locked SMS admin page does exactly that: it surfaces the set of users currently restricted from sending SMS and lets an admin unlock them.Manage Locked SMS (Admin)
What this unlocks for your team
The practical win is turnaround time. Support and trust teams no longer need to escalate to engineering to get a user back to a working state — the review and the unlock happen in the same place, by the person who already has the context. It also means the lock mechanism itself can be more aggressive without paying a support-cost tax, because the reversal path is cheap.
Second-order, it gives us a single funnel to observe. When every unlock flows through one admin surface, patterns become visible: which heuristics over-trigger, which cohorts get caught most often, which unlocks get reversed later. That's the data we need to tune the underlying restrictions, and we didn't have a clean place to collect it before.
What's next
This release is intentionally scoped to the review-and-unlock loop. Next we're looking at richer context on the panel itself — why a user was locked, and prior history — so admins can make the call without cross-referencing other tools. If you run trust or support operations and have opinions about what belongs on that page, we want to hear them.