Our smartmove platform must send customers various types of notifications. A variety of types of notifications meet a wide range of communication channels. For example, there are notifications about app updates, upcoming bookings, account openings, etc. which could be delivered via email, SMS, push notification or in-app banners. In order to meet all these requirements in the e-mobility sector, we have decided on a special, dynamic implementation and would like to share it with you in this blog post: The Customer Messaging Service.
The basic idea behind this service is not only to be able to cover the wide range of message types, but also to be able to expand them during operation. At the same time, the service should be able to send any message as events dynamically via multiple channels (in-app banner, push notification, email, SMS) to affected customers.
In traditional customer notification implementations, the news sources and types of notifications cannot be added and adjusted on the fly. Furthermore, pairing the sources with the appropriate notification types can be very time-consuming and resource-intensive. Our customer messaging system therefore sets a new, innovative standard for flexible customer communication.
Benefits of dynamic event implementation
The architecture of our customer messaging service allows us to dynamically add new news sources. Using a simple and editable configuration, the service can be taught how to deal with new types of notifications (e.g. when the smartmove platform is extended to include notifications for pending app updates). See the process in the image above. Other microservices order the Customer Messaging Service to send a new message. Based on the configuration, the Customer Messaging Service recognizes what type of message it is (e.g. “pending app update” message, “booking start soon” message) and can interpret and process the data accordingly. The messages from the microservices, which are then interpreted and sent by the customer messaging service, are in JSON format but have no other content requirements. In addition, the delivery method (in-app banners, push notifications, email, SMS) can also be dynamically configured for any type of customer notification. This design therefore enables long-term use of the customer messaging service without the need for new implementation costs!
As mentioned in the introduction, all these configuration adjustments are possible on an ongoing basis. The customer messaging service does not have to be redeployed, which means that there are no delays in sending messages due to downtimes. With our service architecture, we have even gone so far that configurations can be adapted using REST interfaces. This means that in future, it would even be possible to map processes in administration software such as our web portal that result in new types of notifications. The necessary adjustments to the customer messaging service can be carried out completely automatically without interrupting ongoing operations.
We have therefore created a very flexible and resilient system. Through generalizations during the design phase of the service, we are prepared for future developments in the smartmove platform. Further adjustments to the dynamic customer messaging service are hardly necessary.
Challenges of dynamic event implementation
Of course, we also faced some challenges in implementing such a versatile system, which we would like to share with you.
As discussed above, a configuration can be stored in the Customer Messaging Service that explains how each message of a notification type must be interpreted. For example, there is an interpretation guide for every type of notification. If the customer messaging service receives a new message that is to be sent, it must therefore first recognize what type of notification it is (a password reset, a booking confirmation, etc.). Only then can the data be read and further processed in accordance with interpretation instructions. However, this matching can become complicated as the number of notification types grows. Errors could creep in when writing the configuration file. Although a static implementation does not have this effort, it also loses all flexibility in return.
Another challenge is configuring data imports. Notifications typically contain personalized data, such as the address of a customer by name. Because of our micro-service architecture, the service that orders a notification from the customer messaging service usually does not have all the data. For example, there is only one customer ID, but not the entire profile. As a result, the customer messaging service must be able to find and use this information. In the end, it should not be “Dear 12345678” but “Dear Martina” in the e-mail. The instructions as to where and how the necessary data can be obtained must be included in the configuration mentioned above. As a result, we had to program the customer messaging service so that it was able to dynamically call REST interfaces from other microservices based on a configuration. Compared to a static solution that retrieves the desired data pre-programmed, this represents a greater implementation effort. However, this was done in the service of great flexibility.
Dynamic > Static
Our dynamic customer messaging service was a major software development project. From conception to implementation, we always had to think far ahead, generalize our use cases and implement complex code. However, we now have a fully developed service that hardly needs to be changed in order to meet future communication requirements. Its applications can be expanded without the need for new software development. Only the connection of a new communication channel requires adjustments. This is very different from static implementation, in which every use case is firmly programmed in. In the end, we have received a system that has been tested and tested and no longer needs to be constantly adapted. As a result, a variety of errors due to regression can be avoided and development costs can be significantly reduced. And at the same time, we provide a helpful user experience for our customers by creating flexible communication channels.
