OptiBiz1
Active Member
A little bit of our journey...
Promotional SMS... (and transactional, but the need for scalability is not that big then)
So many ask for it, but I believe that most doesn't really think of the consequences - do you?
We are currently at the end of a project to rebuild our SMS feature to something VERY potent and scalable in EXTREME. With customers potentially sending 3-50 million SMS per campaign, we had to do something.
We provide a white labeled SaaS based on MW for email and SMS, where we consider MW a platform that we have added a lot of features on top of it, but we have rebuilt much of it to also handle SMS, partially in a form of a set of plugins. Our SaaS can send regular textual SMS, either promotional or transactional, but we can also send newsletters that way and this became quite tricky due to the need for server capacity and to make that possible it required some serious thinking to come up with how to do, and we did. I am not into describing every detail of this as it is on a serious bleeding edge with something that is really competitive for us, where companies FAR bigger than ours were involved to review and confirm / deny whether our ideas should be possible to implement and yes they did confirm it and we know that now.
Just imagine this. Let's say that our reseller has a customer that sends an SMS campaign to 10 million mobiles and it is a promotional offer. We know from statistics from the US that 98% of those who receives an SMS opens it within just a few minutes. If there is a link in such SMSs, the CTR for SMS is around 19%. The number who receives the SMS varies with country, network and quality of the telecom providers' networks. Let's assume a success rate of 90%, so 90% of the SMSs that are sent, reaches the SMS inbox. Further assume that each newsletter can link to 10-20 resources that are needed to show the newsletter. Now it suddenly becomes very interesting because within just a few minutes (depending on our sending speed of the SMSs) the one who created the campaign which sends the newsletter via SMS suddenly have created 10,000,000 * 0.9 * 0.98 * 0.19 = 1,675,800 visitors to our servers and between 16,758,000 - 33,516,000 hits on our server(s) that serves the newsletter. On top of this we get a massive set of web hooks to handle) in this case 0.9 * 10 millions). This within a short period of time.
(We will also gather in-depth statistics for this and build stats and segmentation attributes on the fly using bleeding edge technology, but we are not there yet.)
This from ONE campaign, a quite big one, but still...
Now just imagine this: What-if we have as few as 50 customers sending an average of 5 million SMS each during one day, this gives a total of 250 million SMSs that day. With the above formula we now have 41,895,000 visitors to our servers during the day split up in short time periods, some might even occur during roughly the same time. The number of hits (with an assumed number of assets linked in between 10-20, this means that we have a total of 418,950,000 - 837,900,000 hits during the day or much less. Not to mention the massive amounts of webhooks that we need to handle which in turn will render in roughly 30-40 times the number of database calls which we handle in a very special way. Luckily we will be able to put some things onto the CDN (thanks @twisted1919 for having that as part of the platform already), still this is some crazy a** things that we are doing because that alone will not solve the needs for power.
(and of course our A/B testing / split testing feature and most of the other features that we have, are possible to be used when the newsletters are carried by SMSs too).
The cool thing is that we have solved this. Our problem is that big telecom companies' networks are not as fast as our solution when receiving our API calls.
So, asking for a bulk SMS feature might seem easy to start with, but I promise you that it's **MUCH** more complex than most people can even imagine, at least if you want to provide something of real value, a great user experience and a great value to the customer who sends the SMSs (the company that runs the campaigns to their offer).
---
Our SaaS is, as I mentioned, a fully white labeled, re-brandable solution intended for resellers to sell as if it is their own. The cost, which is intended to cover our 2nd and 3rd line reseller support (while the reseller handles 1st line support so that the white label stays intact), is really low per quarter and on top of that we apply a revenue share model. We are also one of the cheapest on the market when it comes to price per SMS. This is possible since we go directly to the networks, not via a wholesaler who has a distributor who has a reseller that resells it, like most others. I see many competitors for textual SMSs only that charges around 9-10 times more than our prices, some even higher than that. A reseller of ours can of course choose to increase our prices, the revenue share model is still applied. This way our solution is adaptable to each market with that market's prices.
Promotional SMS... (and transactional, but the need for scalability is not that big then)
So many ask for it, but I believe that most doesn't really think of the consequences - do you?
We are currently at the end of a project to rebuild our SMS feature to something VERY potent and scalable in EXTREME. With customers potentially sending 3-50 million SMS per campaign, we had to do something.
We provide a white labeled SaaS based on MW for email and SMS, where we consider MW a platform that we have added a lot of features on top of it, but we have rebuilt much of it to also handle SMS, partially in a form of a set of plugins. Our SaaS can send regular textual SMS, either promotional or transactional, but we can also send newsletters that way and this became quite tricky due to the need for server capacity and to make that possible it required some serious thinking to come up with how to do, and we did. I am not into describing every detail of this as it is on a serious bleeding edge with something that is really competitive for us, where companies FAR bigger than ours were involved to review and confirm / deny whether our ideas should be possible to implement and yes they did confirm it and we know that now.
Just imagine this. Let's say that our reseller has a customer that sends an SMS campaign to 10 million mobiles and it is a promotional offer. We know from statistics from the US that 98% of those who receives an SMS opens it within just a few minutes. If there is a link in such SMSs, the CTR for SMS is around 19%. The number who receives the SMS varies with country, network and quality of the telecom providers' networks. Let's assume a success rate of 90%, so 90% of the SMSs that are sent, reaches the SMS inbox. Further assume that each newsletter can link to 10-20 resources that are needed to show the newsletter. Now it suddenly becomes very interesting because within just a few minutes (depending on our sending speed of the SMSs) the one who created the campaign which sends the newsletter via SMS suddenly have created 10,000,000 * 0.9 * 0.98 * 0.19 = 1,675,800 visitors to our servers and between 16,758,000 - 33,516,000 hits on our server(s) that serves the newsletter. On top of this we get a massive set of web hooks to handle) in this case 0.9 * 10 millions). This within a short period of time.
(We will also gather in-depth statistics for this and build stats and segmentation attributes on the fly using bleeding edge technology, but we are not there yet.)
This from ONE campaign, a quite big one, but still...
Now just imagine this: What-if we have as few as 50 customers sending an average of 5 million SMS each during one day, this gives a total of 250 million SMSs that day. With the above formula we now have 41,895,000 visitors to our servers during the day split up in short time periods, some might even occur during roughly the same time. The number of hits (with an assumed number of assets linked in between 10-20, this means that we have a total of 418,950,000 - 837,900,000 hits during the day or much less. Not to mention the massive amounts of webhooks that we need to handle which in turn will render in roughly 30-40 times the number of database calls which we handle in a very special way. Luckily we will be able to put some things onto the CDN (thanks @twisted1919 for having that as part of the platform already), still this is some crazy a** things that we are doing because that alone will not solve the needs for power.
(and of course our A/B testing / split testing feature and most of the other features that we have, are possible to be used when the newsletters are carried by SMSs too).
The cool thing is that we have solved this. Our problem is that big telecom companies' networks are not as fast as our solution when receiving our API calls.
So, asking for a bulk SMS feature might seem easy to start with, but I promise you that it's **MUCH** more complex than most people can even imagine, at least if you want to provide something of real value, a great user experience and a great value to the customer who sends the SMSs (the company that runs the campaigns to their offer).
---
Our SaaS is, as I mentioned, a fully white labeled, re-brandable solution intended for resellers to sell as if it is their own. The cost, which is intended to cover our 2nd and 3rd line reseller support (while the reseller handles 1st line support so that the white label stays intact), is really low per quarter and on top of that we apply a revenue share model. We are also one of the cheapest on the market when it comes to price per SMS. This is possible since we go directly to the networks, not via a wholesaler who has a distributor who has a reseller that resells it, like most others. I see many competitors for textual SMSs only that charges around 9-10 times more than our prices, some even higher than that. A reseller of ours can of course choose to increase our prices, the revenue share model is still applied. This way our solution is adaptable to each market with that market's prices.
Last edited: