How we choose topics
We write about questions people actually ask about RCS, taken from search demand, from the questions customers put to our team during onboarding and carrier approval, and from gaps we hit ourselves. We do not publish a page because a keyword exists. If we cannot say something more useful than what is already available, we would rather link to the better source.
Who writes and reviews
Content is written and reviewed in-house by the Signalmash team, the same people who run carrier approvals, deliverability, and support for customers. That is deliberate: most of what we publish is operational knowledge rather than research, and it comes from doing the work.
The people who review it, and the subjects each of them can actually speak to: Derek Dempsay on carrier approvals and deliverability; Fazil Parappurath on telecom finance and pass-through fees; and Jeremy Kelley on how businesses actually adopt the channel. Noah Kamrat, our co-founder and CEO, is named only on pieces he writes himself.
Most knowledge-base pages are published under SimplyRCS as an organisation rather than an individual byline, because they are maintained collectively rather than owned by one author. Where a piece is genuinely one person’s work, such as The Texting Trust Tax, it carries that person’s name and links to their profile. We do not attach a personal byline to work that person did not write.
Blog posts are published under SimplyRCS with no personal name unless one person wrote them. What many knowledge-base pages do carry is a named reviewer. The line at the top or foot of a page reads “Reviewed by” rather than “By”, and that wording is exact: the page is written by SimplyRCS, and the person named has checked its claims against what they do for a living. Each one is matched to the subjects listed above, so carrier and deliverability pages are reviewed by the person who runs carrier approvals, and pricing pages by the person who owns the numbers. Nobody is credited on a subject they cannot speak to, which is the same principle as not inventing a byline.
How we source and label statistics
Every figure we publish is attributed to a named source and dated, and linked to the primary source wherever one exists. We link the original announcement or filing rather than an article about it.
We also label where a number came from, because it changes how much weight it deserves. A statistic from a messaging provider about its own traffic is marked vendor-reported. Vendor data is often the only data available in a young category, and it is genuinely useful, but it is not independent research and we do not present it as though it were. Industry estimates and projections are labelled as estimates, with the firm named.
When we cite a competitor’s pricing, we link that competitor’s own published page and date the check, so you can verify it or catch it when it goes stale.
How we keep pricing honest
Published pricing is the claim we are most careful about, because transparent pricing is the thing we ask people to trust us on. Our rates appear on the pricing page and are explained line by line in billing transparency.
Those figures are also checked automatically: our build fails if a price quoted elsewhere on the site no longer matches the pricing page. It is a small safeguard, but it means a rate change cannot quietly leave a stale number somewhere else on the site.
How we update and correct
RCS changes quickly, so pages carry a last-updated date that reflects when the content was actually revised, not when the site was last deployed. Reports built on external data, like the State of RCS, are revised when significant new figures are published rather than on a fixed schedule.
That date is held per page and shown on the page, and it is the same value search engines read from the page’s structured data, so what a reader sees and what a crawler sees cannot disagree. It moves only when the substance changes. Fixing a typo, adding a link to a sibling page, or redeploying the site does not move it, and a page that has not been revised since it was published says so rather than borrowing a newer date from a page beside it. A date that only ever means “recently touched” tells you nothing, and we would rather show an old date honestly than a fresh one we did not earn.
If you find something wrong, tell us at [email protected] and we will correct it. We would rather fix a page than defend it.