One problem many businesses face is sending transactional text messages to their customers and, while there are a large number of third party providers out there including MessageBird, Nexmo and Twilio, it may not always be cost effective to use one. I found myself in this exact situation and needed to find a solution fast.
By purchasing business-tariff SIM-only contracts which could be inserted into Android mobile phones, I was able to provide an automated two-way messaging service between a booking system and customers by constructing a bespoke SMS app.
The app would have to be built for Android as it allows for the default text messaging app on the phone to send messages automatically without interaction from the user. It would not be able to be uploaded to the Play Store however, but that was not a problem since it would only be my booking system using it.
The first step was to set up an API which the app could download the messages it needs to send from. This was built at speed using the Laravel framework, making use of the Laravel packages Sanctum and Fortify to handle authentication. An endpoint was included which allowed POST, PUT and GET requests for fetching, creating and updating messages. A second endpoint was included which allowed new devices to be created and removed, as the solution needed to be able to divide the messages between multiple handsets.
Now that the API was in place, I could begin development on the Android app. Using Kotlin, the app was originally built to poll the server at a regular interval to check for new messages. When it found new messages, it would download and automatically send them to the intended recipient.
Upon successful sending of a message, the result was captured from the intent and sent back via PUT request to the API. This would update the sent status so the client would be able to track delivery within their CRM. When a message was received by the app, a POST request was sent to the API so they could also view received messages.
Once this process was working nicely, I could begin improving the service. Making use of websockets, I was able to keep a constant connection open between the devices and the API. This removed the need to poll for new messages as frequently as the messages could be sent and received in real-time. If the device's socket connection was active, the message would be sent in real-time, otherwise it would be picked up by the less frequent polling later on. Using the websockets helped reduce the number of requests to the API and generally improved performance.
Obviously, there are still costs involved when using this solution, and our job was to reduce the costs of using third party providers and keep the new costs to a minimum. There are two major outgoings for this project:
In this case, the mobile phone handsets chosen were past model Pixel 3As. Other models of phone including Samsung and OnePlus have a reputation for killing apps that run in the background. Using the Pixel models allowed us to get around this, and they were fairly cheap at around £100 per phone. These would be one off costs.
As for the mobile phone contracts, we contacted a provider and was able to get a multi-deal where the price for each SIM was £3 per month. As the devices would be permanently situated in our client's office with a Wifi connection, we were able to choose a deal with the least amount of mobile data they'd offer, with each SIM coming with unlimited text messages. Speaking with the provider over the phone, they were happy with the usage and automation of sending, as long as bulk text messages to lots of people were not sent - transactional and personalised messages were fine.
Overall, spending went from around £1000 per month using a third party provider to just £6 per month using the new app.