Build a marketing suite inside your POS

Sell a merchant outcome, not another inbox

A merchant does not need another empty campaign dashboard. They need a useful way to tell an opted-in customer that an item is back in stock, announce a product launch or reconnect with customers who asked to hear from them.

A POS platform can connect those workflows to the products, locations and purchase events the merchant already manages. That context can make an embedded marketing product more convenient than exporting customer lists into a separate tool.

The opportunity is not simply to mark up a text message. It is to package audience selection, templates, scheduling, permissions, reporting and messaging into a product merchants can use inside their existing workflow. Those are the parts that give an add-on a reason to exist.

Build recurring revenue beyond payment processing

An embedded suite can support a monthly software add-on, a clearly defined usage allowance, transparent overages or a combination of those models. The right package depends on the merchant's size and the value of the workflow—not only the underlying send rate.

For example, imagine your POS platform prices its own marketing add-on at $79 per merchant per month. At 100 paying merchants, that is $7,900 in monthly add-on revenue before costs. This is a hypothetical retail price for your product, not a Blocx plan or a revenue forecast.

Your contribution depends on adoption, actual usage, pricing, support and the complete cost of running the service. A merchant who keeps using a helpful marketing product may support another recurring relationship with the POS platform, but retention and margin improvements should be measured rather than promised.

Give merchants a marketing suite inside their POS

Put campaigns, customer segments, a message composer, internal automations and performance reporting in the same workspace the merchant already uses to run the store. The product mockups in this guide show a merchant-facing suite your POS team can build—not a separate Blocx dashboard or a claim that Blocx supplies the finished application.

A store manager should be able to choose an eligible audience, write a promotion, preview the text, see the billable segment count and approve a budget before scheduling. Show which customers have SMS permission, how many have opted out and why any customer is excluded. Keep the purchase history, location filters and permissions inside your POS product.

The campaign workspace should connect the message to a merchant outcome: promoting a new collection, filling a quiet afternoon, rewarding repeat visits or following up on a requested stock alert. Delivery reports come from your messaging integration; revenue reporting requires your POS to connect campaign activity to purchases using a defined attribution window.

The 3–5¢ SMS selling range

Use 3–5 cents per billable SMS segment as a merchant retail pricing benchmark for your business case. It is a planning range, not a measured market-wide average: bundled allowances, geography, carrier charges and longer messages change the effective price in competing systems.

At 3,000 outbound segments per merchant each month, that range produces $90–$150 in SMS revenue per merchant. At the midpoint of 4¢, the merchant pays $120. That is usage revenue, separate from any software subscription you choose to charge.

The model below uses Blocx's published Scale base rate of $0.0045 per US 10DLC SMS segment and an assumed $0.0035 carrier allowance per segment. Together they produce $24.00 of modeled transport cost per merchant. Replace the allowance with the actual carrier mix and fees on your invoice; it is not a carrier quote.

Contribution here means SMS revenue less modeled base transport and the carrier allowance. It is not net profit. It excludes inbound replies, phone numbers, brand and campaign registration, other provider charges, support, infrastructure, payment processing, taxes, refunds, sales and product development. A long or Unicode text may use multiple billable segments.

What 100 active merchants could produce

With 100 merchants each sending 3,000 segments monthly, the portfolio sends 300,000 segments. At 4¢ retail, that is $12,000 of monthly SMS revenue, $2,400 of modeled transport cost and $9,600 of contribution before the other costs listed above.

Across the 3–5¢ range, that same usage produces $6,600–$12,600 in monthly contribution before those other costs. This is a scenario based on paying merchants and actual sending, not guaranteed adoption, earnings or merchant campaign performance.

This portfolio example assumes an approved account and commercial structure in which the combined traffic qualifies for Scale. The $1,350 in monthly base SMS usage is above Scale's $1,000 minimum, so the minimum is already covered—not added again. Scale still requires an annual agreement; its no-minimum ramp lasts the first 30 days. Do not apply the pooled example to separately billed merchant accounts without confirming their own minimums and eligibility.

You could also charge $79 per merchant for the software itself. At 100 merchants, that adds $7,900 in subscription revenue only if SMS is billed separately. If the subscription includes a message allowance, allocate that allowance and its cost instead of counting the same messages as additional revenue. Software revenue has its own operating costs; it is not automatically profit.

Build internal automations around store events

The recurring value comes from workflows that run inside your POS, not from asking merchants to manually rebuild every audience every week. Your application owns the automation rules and scheduler. Blocx is the delivery layer your backend calls after those rules and consent checks pass.

Give each workflow a clear trigger, audience condition, delay, message, sending window, budget and stop condition. Let a merchant preview the resulting audience and message, approve the workflow and pause it. Show the next scheduled action and a useful reason when a customer is suppressed.

• Post-purchase follow-up: after a completed purchase, wait until the chosen follow-up window and send a relevant merchant-approved message to eligible customers. Cancel or change the sequence after a refund.
• Win-back: identify opted-in customers with no purchase for 45 days, wait for the location's allowed sending hours and send a relevant offer. Exit the workflow as soon as the customer purchases again.
• Birthday or loyalty reward: use a voluntarily supplied birthday or earned loyalty milestone, select an eligible audience and issue a store-specific reward. Avoid collecting unnecessary personal information.
• Back in stock: when an item becomes available, notify customers who explicitly requested that item's alert, then close the alert rather than adding them to unrelated marketing.
• Abandoned online checkout: use your connected commerce checkout event, check the customer's permissions and stop the reminder if the order is completed. An unfinished checkout alone is not marketing consent.

Enforce a cross-campaign frequency cap, quiet hours, opt-outs and message deduplication before each send. Recheck consent at send time, not just when the workflow starts. Process delivery events and purchase events separately: a delivered message is not a sale.

Use SMS and email for different jobs

Lead with a small set of workflows that fit the channels. SMS is useful for short, timely messages and a clear next action. Email gives a merchant more room for product collections, richer explanations and campaign content.

• Back-in-stock SMS: notify a customer who specifically requested an alert for an item.
• Product-launch email: share a collection and details with customers subscribed to the merchant's marketing.
• Time-limited SMS offer: send an approved promotion to an eligible, opted-in audience, with a clear expiry and opt-out handling.
• Repeat-visit campaign: use merchant-approved audience rules and a relevant offer rather than repeatedly contacting everyone in the database.
• Order or pickup updates: keep transactional notifications separate from marketing intent and its consent requirements.

Give each channel its own permission and preference checks. An email subscription is not automatically SMS consent, a purchase is not automatically a marketing opt-in, and switching channels is not a way to bypass an opt-out.

• Messaging workflows for e-commerce
• Marketing campaign workflows
• Blocx email services

Calculate contribution from the whole bill

At the current published Scale unit rates, 3,000 outbound US 10DLC SMS segments at $0.0045 produce $13.50 of base usage. 3,000 emails at $0.0002 add $0.60. The combined base-usage subtotal is $14.10.

That subtotal is not a standalone merchant plan, a complete invoice or a profit estimate. Standard Scale is an annual contract with a $1,000 monthly minimum beginning on day 31 after its first 30 days with no minimum. Usage that qualifies toward the commitment is credited toward it; do not add the minimum on top of the same usage.

Before pricing a merchant package, confirm the approved account structure and how commitments and billing apply to it. Do not assume that traffic from separate merchant brands can always be pooled, or that every merchant needs an identical standalone plan.

Allocate the complete provider bill once, including the applicable minimum and the charges actually on that bill. Account for carrier surcharges, phone numbers, registration, sender/domain costs and any other applicable fees without counting them twice. Then include your own infrastructure, billing fees, support, sales and product operating costs.

The difference between your retail charge and a base send subtotal is not your margin. Use the current rate card and actual usage to model contribution, including quieter merchants, heavier senders, multi-segment SMS and any costs outside the provider invoice.

• Current plans, calculator and full rate cards
• How carrier passthrough fees affect messaging costs

Own the merchant experience; use Blocx for delivery

Your POS application owns the merchant-facing product: campaign screens, approved templates, audience rules, scheduling, budgets, permissions, reporting and customer billing. Blocx supplies the documented messaging APIs and SDK you integrate into that product.

Start with a server-side workflow. A POS event or merchant action selects an eligible audience, your application checks permissions and consent, and your backend submits the message through the documented API. Delivery events then update your campaign records.

Keep provider credentials on your server. Give merchants only the permissions your product intends, and maintain identifiers for the merchant, customer, campaign and individual send so support and usage reporting can reconstruct what happened.

Work with Blocx to confirm merchant provisioning, sender registration, email-domain requirements, tenant isolation and commercial terms before choosing an account layout or selling the product. Sharing a provider integration does not automatically establish cross-merchant data isolation, resale rights or a particular billing arrangement.

• Official JavaScript/TypeScript SDK
• Blocx API and webhook reference
• Discuss your POS platform integration

Keep customer profiles and consent connected

A merchant should not have to rebuild its audience from a spreadsheet every week. Keep the relevant customer profile, channel preferences and opt-in context connected to the POS workflow, with an appropriate merchant boundary around the data.

Blocx Contacts can automatically create a profile on a first send and build channel and delivery context over time. Its API-connected customer profile can also hold opt-in context. Your application still has to collect valid permission, record what the person agreed to and apply the correct merchant and channel scope.

Treat suppression as part of the send path, not only the campaign editor. Check current permissions before sending and cancel queued follow-ups when a customer opts out. Do not combine audiences across unrelated merchants just because the same phone number or email appears in both.

For email, plan verified sending identities, reputation and unsubscribe handling appropriate to the merchant setup. Sharing a POS vendor does not make every merchant's audience or sending identity interchangeable.

• How Blocx Contacts builds customer profiles
• Email sender reputation and a careful launch
• Registration, consent and carrier considerations

Make allowances and billing understandable

Define the unit you sell. SMS segments, customer-visible messages and emails are different units; a long text can consume multiple SMS segments. If you bundle an allowance, explain what it includes, which charges remain separate and what happens when it is exhausted.

Enforce per-merchant budgets and permissions in your application. A merchant-level allowance should not depend on a model following instructions or a campaign operator remembering a limit.

Keep marketing and transactional traffic distinguishable, handle retries safely and make repeated delivery callbacks safe to process. A duplicate notification is a bad customer experience, and a duplicate campaign can also undermine the economics of a tightly priced bundle.

• Prevent duplicate SMS and MMS when retrying sends

Start with a merchant pilot and measure value

Launch a narrow, consented workflow with a small group of merchants before building an entire automation catalog. A back-in-stock SMS flow and a recurring product email can teach you more than a large feature list that nobody uses.

Measure adoption, paid merchant retention, revenue, actual messaging costs, support effort and contribution. For the merchant, track the intended customer action alongside opt-outs, complaints and delivery problems. Use a sensible attribution window and comparison group where possible; a sale after a message is not proof that the message caused it.

A texting and email suite can become another product inside your POS—not merely another fee attached to a payment. Build around merchant value, keep the unit economics honest and use Blocx for the delivery layer while your team owns the experience merchants buy.

• Plan your integration with Blocx
• Browse the API reference

Brand identity

Blocx is the programmable messaging product from OtterBlocx, LLC, headquartered in Cheyenne, Wyoming, United States.

Channels

• Live today: SMS, MMS, RCS, Email, Telegram.
• Blocx also offers separate Voice services: VoIP, voicemail, call routing, 2FA via AI caller, and a voice dialer. These are not channels on the messaging or Verify API.

Plans

• Starter — self-serve with $25 in welcome credit for new accounts. Credit covers your first brand, campaign, phone numbers and messages. Paid Starter is $49/month credited toward usage. SMS $0.0065/segment, email $0.001/email (1 sending domain), 1 API key. No MMS, RCS, Telegram, SHAFT or restricted verticals.
• Scale — $1,000/month minimum platform spend (starts on day 31; no minimum for the first 30 days), on an annual contract. Every channel and route type at the published rate card — all rates listed on this site are Scale rates. Signup starts with a call. Required tier for SHAFT and other restricted verticals.
• Volume — custom volume-based pricing negotiated on your traffic profile. Contact sales.

Published rate card (+ carrier passthrough on SMS/MMS)

• SMS: 10DLC $0.0045, toll-free $0.0055, short code $0.007.
• MMS: 10DLC $0.0135, toll-free $0.016, short code $0.018.
• RCS: $0.0135/msg + one-time $1,000 setup fee.
• Email: $0.0002 per email, flat.
• Verify: $0.035 per successful verify, flat.
• Telegram: $0.0045/msg, flat.