Use Cases
Concrete scenarios where a central hub pays off, from ISPs unifying billing and CRM to retailers, portals and reporting.
Who uses STRAX
STRAX suits organisations that run several specialised systems and need those systems to agree. The scenarios below are told through Demo ISP, a fictional internet service provider, and a few of its neighbours. The platforms named are real connectors available in the marketplace.
An ISP unifies billing, inventory and CRM
Demo ISP bills its subscribers in Splynx, keeps its network inventory in NetBox and runs sales in HubSpot. Before STRAX, a new fibre customer was captured three times, and the three records drifted apart within months.
With STRAX, each platform connects once to the hub, and the hub's Customer entity becomes the single definition. Splynx feeds account and payment status, NetBox feeds the installed equipment, and HubSpot receives the unified customer back, so sales always sees live account standing. When Demo ISP later adds Zendesk for support, the connection costs the same as the first one, and tickets join the same customer record. See Why integration is hard for the trap this avoids.
A retailer syncs its store into operations
A retailer sells through Shopify and runs fulfilment and finance elsewhere. Orders used to be re-keyed, and stock levels lagged a day behind.
Connected to STRAX, Shopify orders flow into the hub as they occur, and operations works from the hub rather than from exports. Stock adjustments flow back out, so the storefront reflects what the warehouse actually holds. Finance queries one set of order data instead of reconciling two.
Portals over unified data
Demo ISP's support agents once kept four browser tabs open per call. Its customers had no self-service at all.
On the hub, Demo ISP builds two portals with STRAX's site builder. A staff portal shows each customer's account, equipment, tickets and payment history on one screen, with roles controlling who sees what. A customer portal lets subscribers check their connection, view invoices and log faults. Neither portal required a development team, and both cover every system feeding the hub. See How STRAX works for where portals sit in the lifecycle.
Automating cross-system processes
When a Demo ISP customer's account is suspended in billing, three things must happen: the CRM must be flagged, a ticket must be opened, and the customer must be emailed. Previously this was a checklist that people sometimes forgot.
As a STRAX workflow, the suspension is detected as a data change, and the steps run automatically, in order, every time. Workflows can branch, call external APIs, send email and produce documents, so the same approach handles onboarding, escalations and month-end routines.
One authoritative reporting layer
Demo ISP's monthly board pack once took two days of spreadsheet reconciliation, because billing and CRM disagreed on the number of active customers.
Reporting on the hub ends the argument. Queries run against the canonical data, a scheduled report delivers the pack as a PDF, and every figure has one source. The reconciliation meeting became a decision meeting.
Where next
If these scenarios rhyme with your estate, read What is STRAX? for the platform in one page, check the feature list, or request a demonstration using your own systems as the example.