Our customers trust we deliver their messages. CM's technique therefore focusses on reliability. This is illustrated by the retry system we've built into our SMS platform.
We measure the quality of our system on the hand of the speed of which messages are delivered and the percentage of messages we deliver.
An eye-catcher guaranteeing the delivery of messages is our retry system. We monitor if messages arrive on the phone and if this happens quickly enough. If that does not happen, we send the message again, using another supplier or a complete different medium.
Our SMS system sends the message first through the connection with the preferred supplier. This may, for example, be a telecom operator or a push platform. How the system determines the preferred supplier is a story in itself, which I will elaborate on later on. The connection provides us an immediate answer; it accepts or rejects the message.
If the message is accepted, the provider attempts to deliver the message on the phone after which we receive a 'delivery report' or 'status report'. The message can be delivered or is failed. If rejected, the message is rejected or failed the ‘Retry on Failed' system comes in function. If the message is accepted but not delivered on time (or failed) the ‘Retry on Overdue’ system starts.
Hence there are two retry systems:
Retry on Failed System: for messages that a supplier cannot deliver Retry on Overdue System: for messages that are delivered on time.
In both cases, the system sends the message again using a different connection. Which one depends on, among others, the type of traffic and type of retry. In general, a Retry on Failed will be sent again as an SMS over a direct connection with a telecom operator. SMS is still the most reliable medium to deliver mobile messages.
In the case of a Retry on Overdue the SMS-connection has no buffer. If the message has to wait in a buffer it is usually because the phone is turned off. It is likely the original message is waiting for the phone to be reached. By using connections that have no buffers, we prevent the message is delivered twice.
The first part is the incoming side. That server which come in at connections of our customers and applications running. The original message always comes in from a client system or application.
The second part is the logic and routing. The logic largely contains the retry logic.
The third section, the output side, connects with suppliers. This is where status reports are delivered, which are forwarded to the second subsystem; logic and routing.
The fourth system is the notification logging, in which the message information and message content (encrypted) is saved. This logging is done almost in an instant.
The second part, the logic, decides on basis of a declined or failed status report if sending a retry message is neccesary. The logic sends this message to the incoming side. The second notice uses the same route as the original message. The message has been tagged as ‘retry message’ hence the logic can adapt and change its decisions.
A Retry on Overdue message is sent by a process that periodically consults the logging real-time in order to find unknown messages. If messages do not have a permanent status within the expected time, a retry message will be sent to the first subsystem. As seen with the Retry on Failed this message uses same route as the original message.