Simply RCS — Product Guide

SimplyRCS is a multi-channel messaging platform for SMS, MMS, and RCS Business Messaging, with WhatsApp onboarding and rendering currently limited to development/scaffold use. It pairs registered sender identities (toll-free, 10DLC, short code, and RCS agents) with content tooling, a real-time Inbox, notifications, billing, and a compliance pipeline for Brand KYC and carrier/registry submissions.

This guide walks every surface a customer-side user touches. Operators who run the platform should consult the separate Admin Guide.

The left navigation is organized into customer workspaces: Overview (Dashboard), Channels & Compliance (Company Profile, Brands, Channels, Submissions, Compliance), Audience (Contacts, Subscription Lists, Inbox), Engagement (Bots, feature-flagged Knowledge, Blasts, Content, Assets, Campaigns), Insights (Analytics), Account (General, Notifications, policy dictionaries, Inbox Queues, Team, Billing, and feature-flagged Integrations), and Developer (Portal, Access, Docs). Related pages stay in the same workspace through top tabs.

Table of Contents

1. Getting Started
2. Company Profile and Brand KYC
3. Dashboard
4. Channels (Sender IDs)
5. Compliance
6. Contacts
7. Subscription Lists
8. Inbox
9. Notifications
10. Bots
11. Blasts
12. Content
13. Assets
14. Acquisition Campaigns
15. Analytics
16. Submissions
17. Settings
18. Developer Portal

1. Getting Started

Sign in

Returning users sign in with email + password. Single sign-on via Keycloak is supported when configured for the organization.

Key actions:

• Enter your work email and password, then click Sign In.
• Use the password-reset link if you have lost your credentials.

2. Company Profile and Brand KYC

Before any channel can be submitted to a carrier or registry, the organization must complete the Company Profile. Simply RCS captures the legal business, contact, website, and authorized representative fields used to create the default Brand and prefill channel submissions. Company-profile completeness, SimplyRCS Brand KYC, and carrier approval are three separate states.

Key actions:

• Fill out legal name, EIN, business type, vertical, address, website, support email/phone, and the authorized representative's name, title, and email. The representative phone is optional.
• Read and sign the Brand KYC attestation, then save. The default Brand moves to Ready for review when its current business information and signed attestation are both recorded.
• Review Settings > Brands for each Brand's SimplyRCS KYC state and separate carrier-approval state. Changes required includes the reviewer reason and means the information must be corrected and attested again.
• Editing KYC-relevant information invalidates an older review and requires a fresh attestation. This prevents an approval from silently carrying over to materially different business information.
• Company-profile completeness gates contact import and sender-ID submission. SimplyRCS KYC is a separate launch prerequisite; carrier or registry approval is tracked on the relevant submission.

Tip: Use the legal entity name exactly as it appears on the IRS EIN letter. Mismatches are one of the most common reasons brand vetting fails.

3. Dashboard

After signing in you land on the dashboard. It surfaces messaging volume, active conversations, contact count, and channel breakdown, plus a setup checklist for new workspaces and a rolling feed of the latest submission activity.

Key actions:

• Review aggregate stats (total messages, active conversations, contacts, channel mix) at the top.
• Work the Setup checklist on a new workspace — company info, purchase a number, register a brand, create a bot, import contacts, send your first message.
• Open the Submissions inbox card to jump to in-flight brand and campaign registrations.

4. Channels (Sender IDs)

The Channels page (Sender IDs) is where you register and manage every sender identity for your organization: RCS Business Messaging agents, 10DLC long codes, toll-free numbers, short codes, and WhatsApp senders. Channel cards walk you through onboarding for each type; existing senders show their enabled protocols, attached messaging program, and lifecycle status.

Key actions:

• Use the channel cards to start RCS, 10DLC, toll-free, short-code, or WhatsApp onboarding. The wizard pulls identity fields from your Company Profile or selected Brand and asks only for sender-specific data such as use case, sample messages, opt-in language, and brand assets. WhatsApp is a development/scaffold workflow until SimplyRCS exposes a production readiness source and completes live provider acceptance.
• Use Messaging programs to confirm which senders are approved as primary, fallback, or test senders for a brand/campaign.
• Click any row to see its submission history, protocols, attached program, and channel-specific details. Numbers with voice service include a Call forwarding card for routing inbound calls.
• Filter by channel type, status, or program. The Test vs Go-Live filter separates the two tracks: test/demo senders carry a prominent badge, are trialled on approved handsets, and are never submitted to a carrier; Go-Live senders are on the carrier-approval track for production traffic.

Tip: RCS-first programs should also have MMS or SMS fallback senders attached before live traffic is sent.

5. Compliance

The Compliance page tracks carrier and registry filings for brand vetting and campaign approvals. Brands represent the legal customer identity; campaigns represent approved use cases such as marketing, support, alerts, or authentication. Each row shows the latest external filing decision, score, and review feedback. SimplyRCS Brand KYC remains a separate internal state on Settings > Brands.

Key actions:

• Submit brand — create a new brand using your KYC fields. Choose enhanced vetting if your account team recommends it.
• Submit campaign — pick the parent brand, define the use case, opt-in flow, and sample messages. Campaigns can be reused across multiple sender IDs.
• Drill into a row to see the full audit trail (every submission attempt, review response, fee charged).

6. Contacts

Manage every recipient your organization can message. Contacts have first and last name, a phone number, optional email, custom attributes, tags, and a per-channel consent record. The built-in System Contact Fields (name, phone) double as personalization tokens — <<FIRST_NAME>>, <<FULL_NAME>>, and friends — usable in bots, templates, and blasts alongside your custom-attribute tokens.

Key actions:

• Import — upload a CSV. Simply RCS validates phone numbers, normalises to E.164, deduplicates against the existing list, and shows a preview before commit. KYC must be complete before import is allowed.
• Add contact — manually create a single contact.
• Tag / segment — apply tags or build dynamic segments (country = US AND last_message_replied < 30d) for use in blasts and bots. Tag names are normalised to one canonical form (lowercase, hyphenated — VIP Customer becomes vip-customer), so the same tag can never exist in multiple spellings.

Tip: Consent is tracked per channel. A contact can be opted in for SMS but not RCS, or vice versa. The platform automatically suppresses sends to opted-out recipients on the relevant channel.

7. Subscription Lists

Subscription lists are named groups of contacts that have explicitly opted in for a topic. They are the primary audience selector for blasts and acquisition campaigns and the unit at which double opt-in / unsubscribe is tracked.

Key actions:

• Create a new list and define its keyword (e.g. JOIN PROMO), opt-in confirmation message, and unsubscribe instructions.
• Assign sender IDs that are allowed to send to the list.
• Review subscriber growth, churn, and the most recent opt-in/opt-out events.

8. Inbox

The Inbox is the live two-way messaging surface. Every reply from a contact lands here. Agents can take ownership of a conversation, send a reply, attach files, hand off to a bot, or close the thread.

Key actions:

• Use the filter buttons to switch between My open, Unassigned, All open, Closed, and All conversations, and narrow further by inbox queue or owner.
• Click a thread to see the full message history (including rich RCS card previews), applied tags, and the contact's profile.
• Take this conversation to assign it to yourself and reply inline. Taking over a bot-run conversation pauses the bot; Return to bot hands the thread back when you are done. The composer shows a live SMS segment counter as you type.
• Export current view or Export all to download conversation data.

9. Notifications

The Notifications page is your account action inbox — customer-visible items that need attention or track important account updates (submission decisions, billing events, usage thresholds, webhook failures, security notices, and system messages). It complements, and is separate from, the conversational Inbox.

Key actions:

• Scan the Unread and Visible counts, and toggle All / Unread.
• Filter by category: Submissions, Billing, Usage, Webhooks, Security, System.
• Each item shows its category, severity, body, timestamp, and the delivery status of any matching email notification. Use the per-item actions to mark read or archive, and follow the action link to jump to the page that needs work.
• Use Message SimplyRCS to send a support note to the platform team when a submission or account item needs attention.

Contextual support and privacy handoffs

Contextual Help actions open /support?topic=.... The page names the recognized topic and shows safe account context before opening the approved external support system in a new tab. You can copy the Account # when it is available. Opening the external destination does not create a SimplyRCS support case, SLA, approval, or account change; it is distinct from Message SimplyRCS in Notifications. If the destination is not configured safely, the page says that no request was created and provides a return path.

The public /legal/privacy#rights-requests page explains the boundary between archiving an application record and making a legal privacy-rights request. Archiving is not erasure. Opening the approved Privacy & Legal contact page does not verify identity, start a statutory clock, or create a trackable SimplyRCS request.

10. Bots

Bots are the no-code conversational flows that drive RCS rich cards, carousels, suggested replies, and SMS auto-responders. Each bot is composed of nodes connected on a canvas; the node palette is grouped into Messages (message, card, carousel, list message, JSON), RCS (RCS browser), Logic (condition, go to), Actions (input, assign tag, assign attributes, data capture, execute, human handoff), and Flow (delay, note, end).

Key actions:

• New bot — start blank, or Browse Templates to pick from the full pre-built catalog (appointment booking, restaurant ordering, product catalog, customer support, lead generation, survey & feedback) or any flow your team has saved as a reusable org template.
• Drop nodes onto the canvas, connect them, and edit each node's payload in the right rail. Variable and intent fields are picked from the org-wide Variables and Intents dictionaries (under Settings) via comboboxes, so the same tokens route and report consistently across every bot. Plain message text is capped at 160 characters at authoring time — the counter keeps every message inside a single SMS billing segment — while rich-card titles and descriptions have their own longer limits.
• Use Choice Capture on list and carousel nodes — "Save the customer's choice as" stores the option the customer taps into a variable, the counterpart of Data Capture for typed replies.
• Use Test to run the bot in the built-in emulator that mirrors RCS rendering, or run a live handset test against an approved test device. The test drawer includes a sender picker to assign a sender ID to the bot — test/demo agents are badged and sorted to the top, and the preview re-brands to the chosen sender.
• Publish to attach the bot to a channel and / or a keyword. Publishing pins a snapshot: once a bot has been published, live customer conversations always run the published version, so you can keep editing the draft without affecting live traffic — changes go live only when you republish. A bot that has never been published runs its draft, and handset test runs always exercise the current draft.

AI features (where enabled for your account) add two tabs to the builder. The Assistant edits the flow conversationally — describe a change and it adds, edits, removes, or reconnects steps, including carousels and list menus. The Agent tab generates a knowledge base (FAQs and facts grounded in the bot, plus your own instructions) that you curate item-by-item and try out in a built-in Test your agent chat. Switching on the per-bot live agent toggle then lets the agent handle free-text replies that don't exactly match an authored option: it picks the authored option (from the published flow) the customer most likely meant, or escalates to human handoff — it never writes its own customer-facing text, and on any doubt the conversation falls back to standard keyword behaviour.

Tip: Use Condition nodes to branch on contact attributes (tier == "vip") and Execute nodes to call an external API — <<VAR>> tokens interpolate into the URL, headers, and body.

11. Blasts

Blasts are one-shot broadcasts to a contact list, segment, or subscription list. The composer estimates cost per channel before you send, runs through your active content rules, and queues the messages for delivery on the routes you have configured.

Key actions:

• Choose the audience (subscription list, segment, or contact tags).
• Choose the channel: SMS, MMS, or RCS. RCS programs can fall back to MMS and then SMS when a recipient cannot receive the richer format.
• Compose the message (text, media, suggested replies for RCS) or pick a template from the Content library.
• Review the cost preview, schedule, and click Send or Schedule.

Fallback planning: Simply RCS uses an RCS-first authoring model and can preserve delivery through MMS or SMS where a fallback sender and protocol are configured. The blast wizard shows the primary and fallback previews before launch.

12. Content

The Content library holds reusable messaging assets: message templates, RCS rich cards, and landing pages. Templates can be approved by carriers ahead of time so blasts using them do not need to wait for per-send review. Binary media (images, video, PDFs) lives in the separate Assets library (next section).

Key actions:

• Create templates for common transactional and promotional messages. The template editor uses the same rich-message designer as the bot builder, with guardrail warnings grouped by severity as you author.
• Build landing pages for opt-in flows and short-link redirects. Pages are assembled from blocks — hero, text, image, video, form, CTA, FAQ, testimonials, countdown, and RCS-launch — and an Agent chat block adds live web chat answered by the bot's AI agent on pages opened from a bot conversation (requires AI features enabled for your account, a published page, and the bot's live agent switched on).
• Reference uploaded media from the Asset library when authoring cards and templates.

13. Assets

The Assets library is the organization's media store for the images, video, and documents used in RCS cards, MMS, bot media, brand logos, and landing-page hero images. Assets are organised into folders and served via signed URLs.

Key actions:

• Upload assets — drag and drop or Choose Files to add media. Files are validated and stored durably.
• New Folder — organise assets by campaign, vertical, or brand.
• Reference an asset from the Bot Builder, Content templates, or the blast composer.

Note: Customer assets are durable — binary uploads are persisted in object storage and never wiped by routine deploys.

14. Acquisition Campaigns

Acquisition campaigns are multi-step flows for growing a subscription list — short-code keyword opt-ins, QR codes, web widgets, and click-to-chat deep links.

Key actions:

• Create a new campaign and choose its acquisition surface (keyword, QR, web widget).
• Configure the confirmation flow (single or double opt-in) and the welcome message.
• Track conversions on the campaign detail page.

15. Analytics

The Analytics page aggregates message volume, delivery rates, opt-out rates, click-through, and cost per channel. Drill in by date, channel, sender ID, campaign, or delivery receipt status.

Key actions:

• Compare channels side-by-side to see where engagement is highest.
• Open Intent Taps to see suggested-reply chip taps counted by intent — which options customers actually choose, across every bot.
• Open MO & MDR Downloads to review inbound messages and delivery receipts by primary channel, actual channel, fallback outcome, wireless carrier, sender ID, brand/sender, program, campaign/workflow, status, contact, and receipt time.
• Export CSV reports for offline analysis. Customer reports are scoped to your account and do not show backend routing details or raw delivery payloads.
• Review account notifications and send an in-app support note via Notifications (the action inbox), or use a contextual Help handoff when one is offered.

16. Submissions

The Submissions page is a unified queue of every regulatory submission your organization has filed: brand registrations, campaign approvals, toll-free verifications, short-code requests, and RCS agent reviews. Each row shows the lifecycle state, fee, and any reviewer feedback.

For a toll-free verification, your final submit first creates an Under SimplyRCS review case. It does not immediately file a Brand or campaign with the messaging provider. After SimplyRCS approves and submits the case, the provider campaign progresses through campaign submission, Infobip compliance review, upstream supplier review, and TFN verification. Provider Brand readiness is completed with campaign submission and is not a separate customer-facing review phase. Only Approved — live means the campaign is REGISTERED, provider verification is complete, and the number is send-ready. Provider identifiers, raw Brand/campaign stages, snapshots, and diagnostics remain admin-only.

Key actions:

• Filter by submission type, status, or sender ID.
• Click into a submission to see the full event timeline (request, acknowledgement, review response, fee posted, fee paid).
• When SimplyRCS requests changes—or a Toll-Free filing is rejected—correct the flagged fields and resubmit the same case. The correction creates a new filing attempt and returns it to SimplyRCS review; it does not silently alter an active provider review or require purchasing another number.

17. Settings

General

Update your organization name and review read-only workspace metadata (account number, immutable slug, creation date).

Content Rules

Org-level content policy. Block specific keywords, require disclaimers on certain campaigns, force opt-out language on every promotional send. Customer rules layer under platform and org-admin rules — the more restrictive rule always wins, and the TCPA STOP / START / HELP keywords are immutable.

Keywords

Manage the keyword router. Inbound STOP / HELP / JOIN keywords are mapped to subscription lists, bots, or canned responses.

Intents

A reusable dictionary of postback values. Pick an intent when building a suggested-reply chip so the same meaning routes and reports consistently across every bot. An intent's value (the postback token) is fixed once created — flows match on it — while its label and folder can be edited freely.

Variables

A reusable dictionary of variables for capture and personalization. A scalar variable (Text, Number, Date, Yes/No) is a data-capture slot; a List variable is a set of options a List or Carousel node can show. Each variable's token (e.g. <<FULL_NAME>>) is fixed once created, while its display label and folder can be edited freely. The dictionary also shows where each entry is used.

Inbox Queues

Define the queues that incoming conversations are routed into and assign team members to them. Queues power the All queues filter in the Inbox so handoffs reach the right group.

Team

Invite teammates, assign roles (BRAND_ADMIN, AGENT, VIEWER), and revoke access. Role permissions are enforced both in the UI nav and at every API endpoint.

Billing

Review usage, invoices, rate plans, and payment methods.

Tabs:

• Wallet (prepaid accounts) — current balance, Add Funds, auto-recharge settings (threshold and top-up amount), and the transaction history. Wallet funding itself is not taxed; applicable taxes are calculated when funds are spent on taxable services.
• Usage — current message volume and estimated charges for the selected date range, with a daily-volume chart.
• Invoices — invoice history and invoice detail pages. Stripe PDF download is shown only when an invoice has a Stripe PDF available.
• Rates — read-only Service Plan / Customer Rate Plan rates assigned to your organization.
• Payment — saved payment methods. If Stripe is not configured for the environment, the page shows a disabled state instead of a payment form.

Invoices may include separate operator-fee line items when carrier pass-through charges are reconciled for the billing period. These are intentionally shown apart from message usage so customers can distinguish platform/service rates from carrier-imposed fees.

New organizations start on prepaid wallet billing: fund the wallet, sends draw it down, and auto-recharge keeps the balance above your threshold. Postpaid invoicing is available for established, contracted accounts.

18. Developer Portal

The Developer Portal is a self-service surface for issuing API keys, configuring webhooks, and browsing the supported customer OpenAPI contract. Public integration operations are the routes present in that OpenAPI document; private browser-session handlers used by the UI are not customer API commitments.

Key actions:

• Access → API Keys — create a key, scope it to Messaging operations (messaging), Read-only (read_only), or Full workspace access (full), set an optional expiry, and rotate or revoke. The plaintext secret is shown exactly once at creation (and once on rotation). Expand a key to see its recent request log — the last 50 requests, filterable.

• Access → Webhooks — register a signed callback URL for delivery receipts, inbound messages, submission events, and billing events. The signing secret is returned once. Use the built-in Webhook Tester to send a signed test delivery and confirm your endpoint responds correctly.

• Authenticate requests with Authorization: Bearer YOUR_API_KEY or the equivalent X-API-Key header.
• View the inline OpenAPI spec at /docs/api-reference and download the machine-readable customer spec from /api/openapi/customer.

Reference

• API reference: /docs/api-reference (OpenAPI 3 spec)
• Machine-readable customer spec: /api/openapi/customer
• Status & uptime: contact your account manager for the dashboard URL
• Support: use Notifications → Message SimplyRCS