Case study 02

Velobotix — SMS Gateway API & Portal Platform

Communication · API · SaaS

A multi-tenant SMS gateway where platform owners, resellers, and business customers each get a portal that fits their job — plus a public REST API for developers. One delivery and wallet model sits underneath both, so what the API returns matches what the portal shows.

My role: Product designer & UX researcher — research, UX/UI, design system
Platform: Responsive, installable web portal plus a public REST API
Users: Platform owners, resellers, business customers, and developers
Scope: 20+ feature areas from wallet ledger and sender IDs to campaigns and audit logs

Resellers and Director Customers one platform, two audiences

The challenge

Businesses needed to send and track SMS at scale, but onboarding was slow, delivery status was opaque, and developers and non-technical operators were forced through the same confusing tooling.

Key questions

How might we let a developer go from sign-up to a first sent message with nothing but an API key and one request?
How might we let a non-technical operator send, schedule and monitor messages without ever touching code?
How might we surface cost, balance and sender approval before a send, instead of after a failure?
How might resellers offer the service under their own brand while keeping every tenant's data strictly apart?

What the product had to do

Let a developer go from sign-up to a first sent message with an API key and a single request.
Let a non-technical operator send, schedule, and monitor messages without touching code.
Make cost, balance, and sender approval visible before a send, not after a failure.
Support resellers who resell the service under their own brand, with strict data isolation between tenants.

Design process

This was a systems problem before it was a screens problem, so the work started with the model and only then moved to the interfaces.

Hear both audiences separately

Developers and campaign operators wanted opposite things, so each was heard on their own terms.

Interviews with developers and campaign operators
Review of the API documentation and developer onboarding

Map the model

Traced how money, sender IDs and messages move through three tenant tiers before drawing a screen.

Task analysis of send, schedule and delivery-tracking flows
Wallet ledger, sender ID approval and rate limits treated as system states
Super admin, reseller and customer tiers

Design two front doors

One delivery and wallet model underneath, with a portal for operators and a developer portal beside it.

Bulk sending that explains itself
Guided sender ID approval
White-label for resellers

Check with people who don’t code

Put the portal in front of non-technical users, then refined it with engineering through build.

Usability testing of the portal with non-technical users
Next: measure time to first message and campaign setup success

Pain points

Three audiences needed different views of the same data

A platform owner, a reseller, and a business customer need different things from the same data — and must never see each other’s.

Balance and rate problems appeared only after a failed send

Balance and rate problems surfaced only after a send failed, which made users doubt the system.

No clear status while a sender ID was pending

Getting a sender ID approved involved documents, fees, and waiting, with no clear status along the way.

Bulk sends were a black box

Large sends felt like a black box: users could not tell what was queued, sent, or failed.

Developers and operators wanted opposite things

Developers wanted a key and a working example fast; operators wanted no code at all. One interface could not serve both.

Resellers couldn’t present it as their own product

Resellers needed the service to look like their own product, not the platform’s.

UX research methodology

Stakeholder interviews with developers and campaign operators
Developer-experience review of API docs and onboarding
Task analysis of send, schedule, and delivery-tracking flows
Usability testing of the portal with non-technical users

Key research insights

Two distinct users: developers who wanted a fast API key and clear docs, and operators who wanted to send and monitor without touching code
Delivery status and failure reasons were the top source of support questions — users needed to trust what happened to each message
Balance, sender IDs, and rate limits surfaced too late, so problems appeared after a send rather than before

Problem statement

Developers and operators wanted opposite things from the same platform — a fast API key versus a no-code portal — while balance, sender ID and rate-limit problems only surfaced after a send had already failed, leaving both audiences unable to trust what happened to a message until it was too late to fix.

Who we designed for

Ishara — Backend developer at a retail startup

Needs to add SMS notifications to an app this sprint and wants to avoid a long onboarding.

Goals

Get an API key and send a first message quickly
Understand errors and limits from the docs alone
Check balance and delivery status programmatically

Frustrations

Docs that hide the basic request behind a sales call
Unclear error messages when a send fails
No way to test without spending credit

Malini — Marketing operator

Sends promotional and reminder campaigns to customer lists, with no coding involved.

Goals

Upload a list and schedule a campaign in minutes
Know the cost before she sends
See who received the message and who didn’t

Frustrations

Finding out about low balance after a send fails
Sender ID approvals with no visible status
Bulk sends that feel like a black box

Amal — Reseller

Resells SMS to his own business customers under his own brand and manages their accounts.

Goals

Set pricing and credit for each customer
Present the portal under his own brand and domain
Keep his customers’ data separate from everyone else’s

Frustrations

Tools that look like someone else’s product
Manual top-ups and invoicing
Unclear visibility into customer usage

Design challenges

Two audiences, one data model

A platform owner, a reseller and a business customer all needed different views of the same wallet and delivery data, and none could ever see another tenant’s.

A developer portal beside an operator portal

Developers wanted a key and a working example; operators wanted no code at all. One interface could not serve both without compromising either.

Trust before the send, not after

Rate limits and sender approval had always surfaced as failures. Moving that information earlier meant redesigning when, not just how, it was shown.

White-label without extra complexity

Resellers needed the product to look like their own, which meant every design decision had to work under a different brand without adding a configuration burden for everyone else.

Design decisions

One product, three tenant tiers

The problem. A platform owner, a reseller, and a business customer need different things from the same data — and must never see each other’s.

The decision. Each role gets its own navigation and dashboard. Super admins see every account, resellers see themselves and their own customers, and customers see only their own data, so nobody ever sees a tenant they shouldn’t.

A wallet ledger you can trust

The problem. Balance and rate problems surfaced only after a send failed, which made users doubt the system.

The decision. Every charge and top-up is an entry in an immutable ledger, with hierarchical pricing from platform to reseller to customer. Balance is always in view, so cost is known before a message goes out.

Sender ID approval as a guided flow

The problem. Getting a sender ID approved involved documents, fees, and waiting, with no clear status along the way.

The decision. A request flow with document upload, payment, and a visible status from submission to assignment, so users always know what is pending and what happens next.

Bulk sending that explains itself

The problem. Large sends felt like a black box: users could not tell what was queued, sent, or failed.

The decision. Campaigns send in batches of 40 messages in the background, with automatic retries. The campaign view shows recipient and batch status, and message-level logs explain failures instead of hiding them.

A developer portal beside the operator portal

The problem. Developers wanted a key and a working example fast; operators wanted no code at all. One interface could not serve both.

The decision. API keys are created in the portal and the secret is shown once. A developer page documents the send and balance endpoints, so a first request is one copy-paste away, while operators never need to see it.

White-label for resellers

The problem. Resellers needed the service to look like their own product, not the platform’s.

The decision. Platform branding and reseller white-labelling (slug, custom domain, colours, and login templates) are configurable from settings, so each reseller’s customers land in a branded portal.

My role and process

I was the product designer and UX researcher for the whole platform. I interviewed developers and operators, reviewed the API documentation and onboarding, and mapped the send-and-track journeys. From that I designed the wallet, sender ID and campaign flows across the three tenant tiers, along with the shared interface system, and stayed with engineering through the build so what shipped matched what users had tested.

Tools and skills: Figma, Design system, Prototyping, Usability testing, Developer experience

What I'd do next

Measure time-to-first-message for developers and campaign setup success for operators inside the product, so the improvements can be tracked over time.