Church security communication FAQ

TEXT is SMS-first: check-ins, supervisor broadcasts, direct messages by name, and an admin console for oversight - no installs required.

It is built to keep communication quiet during worship, while still giving leaders the visibility and control they need.

No for TEXT. It is designed for interactive text messaging - no app download required and it can work without Wi-Fi.

SMS is built for small, store-and-forward style messages on the carrier's messaging paths. Consumer chat, maps, and VoIP need a steadier IP session and more round trips. When the network is congested or the handset is in a weak pocket of the building, that difference shows up first in anything that behaves like continuous data - not always in a single short text.

Payloads are tiny compared with sustained voice streams, so structured commands such as CHECKIN, STATUS, and short directives often complete when a voice or data app would not stay up. For a longer campus-focused version of this topic, see radios vs SMS dispatch.

No. SMS is best-effort like any network service. What you usually get on a phone is a clear sent state, a visible failed-to-send state, and a prompt to retry when the handset could not complete delivery - which is easier to reason about than a "connected" icon hiding dropouts on a live stream.

The practical claim is narrower: in many real campuses, a short structured text is more likely to complete (or fail visibly so someone can retry) than a sustained VoIP or group-data session when coverage is thin. Always validate with walk tests on your own building and carrier mix.

Yes. Most teams start with SMS-first operations for speed and simplicity, then enable premium modules and policy refinements as needs evolve.

Yes. TEXT is designed to protect personal contact information and still enable fast coordination through structured messaging and role-based routing.

Team members text CHECKIN to mark themselves on duty and CHECKOUT to go off duty. Only checked-in members receive standard supervisor broadcasts.

Authorized roster members (people approved on your TEXT workspace, not the general public) can text STATUS to see who is currently on duty.

Yes. TEXT supports direct messaging using @Name. If multiple people match, the system prompts you to choose.

Broadcast behavior is role-based by default: supervisors and owners can send team-wide broadcasts, while ordinary member messages are treated as replies and routed to supervisors for visibility.

Owner configuration: Owners can change who is allowed to send team-wide broadcasts in product settings (admin), so broadcast authority stays aligned with your security policy and does not depend on informal habits in the thread.

New members can text JOIN. The system asks for their name, and if approvals are enabled the request goes into a pending approval queue for a supervisor/owner to approve.

The public dashboard (/) is a read-only status view. The admin dashboard (/admin) contains team management, message history, queue health, and operational tools.

It is based on unique users who actively use the product during the month. Billing is based on monthly active users, not total roster size, shifts, or days used.

Inbound and outbound SMS/MMS messages each count as one usage unit. Every plan includes 250 monthly messages, then usage is metered at $0.03 per message.

No. Included message allowance resets monthly.

Several operational behaviors are configurable per client, such as who can send team-wide broadcasts, automatic checkout timing for inactive users, and how long alert/message records remain visible before expiry.