It’s not uncommon for an organization with a high-volume of SMS traffic to put up their business for bid and ask several SMS providers for proposals.
Bids, or tenders, are long-winded processes involving multiple decision makers and three or more SMS providers. The simple decision seems to be choosing a provider based solely on price. That’s completely understandable – SMS costs occupy a line on the monthly expense report and minimizing costs is logical. And SMS definitely isn't something that comes to mind first thing in the morning, or last the last thought before bed (at least we hope not.)
However, there are clear risks following that train of thought. So here are important things to consider when selecting a global SMS provider.
All proposals should be somewhat close in price, as SMS provider costs from network operators and hubs are relatively the same when comparing routes in the same country, on the same network, with similar delivery rates.
If there is an outlier in the proposals with a significantly lower price, it’s questionable. Is the provider trying to win the business by running a loss, then raise the price in the future? But that doesn’t make business sense in this industry (there’s nowhere to make up the loss.) We’ve found that proposals offering a significantly lower price are comprised of gray routes. This poses a risk for the client, as messages can ultimately be undelivered at high rates (like, all of them,) and they still incur costs. Gray routes are typically connections with network carriers that are not contractual, and the provider is exploiting a loophole. The carrier can shut off the connection without the client or the provider ever knowing.
We've come across such cases in the past. One case involved a lengthy tender, with the bid granted to the (significantly) lower proposal, and their software was deployed. There was only one small issue –the provider did not establish legitimate routes with operators and hub. Essentially, the client was sending messages through a provider who was unable to deliver those messages, while being unaware that they were undelivered. Imagine the alternative costs incurred by the client.
Some primary reasons businesses outsource SMS messaging is to forgo building the software, brokering the networking connections, and maintaining the system. With high volumes, things can go wrong, and it’s the partner’s responsibility to maintain delivery rates and re-route connections when needed.
Uku describes support as the foundation to good software products and APIs. Whether it be having a real person to call to discuss time-critical cases, or a transparent way to find solutions, having one point of contact is invaluable. In addition, it simplifies geographical expansion and monthly administration.
So, understanding how support is handled is crucial to direct or indirect costs. Is support from an account manager factored in the price or is it an additional cost? If support is not included and a client does not buy support, the responsibility falls on the client’s tech team, which costs the client indirectly from the cost of the service.
The SMS provider must be able to go where the client’s company goes, otherwise the client will end up looking for another provider to support a different geographical region. Eventually, clients manage a mess of several APIs to do the same thing (and separate tenders for each region.)
Does the SMS partner align with the company’s growth plans and do they understand the company’s business processes? Do they exist in regions we want to go, or do they plan on going to those geographical markets to forge new connections?
Expanding geographically or offering new services means that the SMS partner must be able to scale with the client, whether it be connections in geographical markets the client intends expand to, or the same breadth of services across the world. Looking to the future leads to a better decision, which builds a stronger partnership, while reducing the indirect costs of repeating the bid process in other markets.
More to come next week…