SMS-Magic, implemented so every conversation lands in Salesforce

Yes. SMS-Magic, built by Screen-Magic Mobile Media, is being brought to market under the name Conversive — the Salesforce experience is rebranded Conversive for Salesforce, with the same underlying capabilities and workflows. Both names are still in circulation across listings, documentation and search results, so you may see either one during procurement. If you already run SMS-Magic, you are running the same product line.

The practical line is this: if it can be built in Salesforce setup, in Flow, or in the package's own admin screens, it is configuration — templates, merge fields, routing rules, triggered sends on stage or status, reports and dashboards. If it needs Apex, a Lightning Web Component, or a call to a system outside Salesforce, it is custom development. Bulk sends that have to respect governor limits, messaging driven by custom objects, and bespoke agent screens all fall on the development side. We tell you which side a requirement sits on during discovery, because the two are staffed and priced differently.

A focused first use case is typically a few weeks of build once discovery is agreed, and the package itself installs in an afternoon. The variable that most often sets the real launch date is carrier registration: US business messaging requires brand and campaign registration for 10DLC numbers, or verification for toll-free numbers, and that approval runs on the carriers' timetable rather than ours. We file it in the first week for exactly that reason. Custom development, multi-team rollouts and multi-country number coverage extend the timeline beyond that baseline.

We design consent as a field on the Salesforce record rather than a list held elsewhere. Opt-ins are captured wherever the customer gives them — a web form, a portal, an agent screen — and written to that field. Standard stop keywords update it automatically on reply, and every automated send checks it before dispatching. That gives you an answer to "who consented, through which channel, on what date" that can be produced from a report instead of assembled by hand. Twopir builds the mechanics; your legal team owns the policy those mechanics enforce, and nothing on this page is legal advice.

Yes to both, and they solve different problems. Flow is where operational messaging belongs — a reminder timed off an appointment date, a nudge when a lead sits untouched, a notification when a case changes stage. Marketing Cloud is where campaign messaging belongs, with SMS running as a consented step inside a journey that already sends email, rather than as a separate blast from a separate tool. Where the trigger comes from a custom object or a system outside Salesforce, we build it in Apex instead.

That is a common starting point, and the cause is usually the same: the package was installed but never wired into the process, so using it is extra work rather than the fastest way to do the job. We audit what is configured today, find where the process and the tool diverge, then rebuild the parts that matter — triggers on the events that should cause a message, routing that gives every reply an owner, templates people can actually send, and reporting that shows what changed. It rarely requires starting over.

It depends on who needs to control the messaging and how much of it is bespoke. A packaged application like SMS-Magic gives business teams templates, a conversation view and admin screens they can run themselves, which suits sales, service and marketing use cases. Building directly on a programmable platform such as Twilio gives developers more control and usually makes sense when messaging is embedded in a product or a highly custom workflow, at the cost of building the business-facing tooling yourself. We deliver both, and the decision usually turns on who owns the numbers, what the compliance surface looks like, and how much custom logic you expect to need.