Innovery experience has made it possible to build a suite of services and products adaptable to customer needs that can provide a wide Notification management platform to centralize all customer communications in one place and have an overall vision interactions with users.
INM – Notification flow
Onboarding
Custom fields definition: each fields will be defined with the name and the type and the description.
The fields will be used by the Engine to handle the logic to identify the agreed template for the given Business Scenarios.
API/(S)FTP Interfaces – Emai Input Channel
INM receives the request via file or API and will insert it into an Apache Kafka queue.
Dynamic IN-DB Interface
INM will connect to a stated set of W3’s DBs and will collect the values of the defined fields in order to fullfill user’s data and then create the proper records to be inserted into system (i.e. to create the message for Campaign Management)
Delivery
The output of the Evaluation will be inserted into a queue of Apache Kafka, that is consumed in order to send the messages to the user.
Evaluation
INM will then create the proper records to be inserted into an Apache Kafka queue. A module of INM consumes from the input queue and sends the request to the ENGINE. Thanks to the input parameters provided in the notification, INM Engine is able to evaluate the request and to generate the messages. Notifications will be elaborated, dynamically enriched with other parameters (i.e. the sender, the scheduled time of delivery, etc.) and then delivered to the users.
Catching&Caching capability INM will connect to a stated set of W3’s DBs and will store in its cache the user’s data (i.e. language, user-name, notification channel, ect)
INM will set expiry dates (TTL) at records level in order to purge old data and will poll and ask the DBs for new data periodically in order to keep the cache updated. External systems can invalidate the cache on demand.
INM Service Examples Overview
- Each notification can be enriched dynamically by external processes and customer/users parameters
- Each notification can be sent in several ways and also retries can be set. It is possible, for example, to send an email first and then after a set interval an SMS or API REST notification (e.g. in case of failover)
- For each business scenario it is possible to configure the sending time window (e.g. from 7am to 22pm or always immediate)
- Based on business scenario you can edit text and email html template from GUI
- It is possible to test the individual business scenario by setting the destination to which the notification is sent
- Based on business scenario different senders can be selected
Features
- Short, concatenated SMS and flash SMS
- SMSC logging interaction to check if SMS is sent/delivered
- SMSs dispatching in specific time window based on SMPP capability
- Dynamic SMS Sender based on business scenarios
- Html email templates
- Email delivery acknowledgement
- Dynamic email sender based on business scenarios
- API Integration (HTTP/HTTPS, REST, customized)
- Push App
- WhatsApp templates
- Files (SFTP, input email)
- EDR collection for monitoring, accounting and reporting
- Log collection, management and exporting
- Metrics and alarms towards OSS systems
- Multi-AZ, Highly scalable and customizable
- Apache Kafka to enforce queue management
- Custom algorithmic solutions & configurable decision flow (Engine Module)
- Multi Tenant/Brand/Market Segment platform
- Shared offer handling with different messages (type and text) to MASTER and SLAVEs
- Bulk Campaign Management
- Throttling management tuned on interfaces capacity
- Customer UI for configuring the text of the messages for preconfigured business scenarios
- Failover rules for delivery retry
- Tone of Voice Feature: based on the Customer/User choice, INM can select User categories (young,senior,etc) to differentiate the Tone of the message
- Catching&Caching data from external systems
- User TypeMsg Feature: based on the Customer/User choices, INM can select the type of notification (SMS,WhatsApp,ecc) automatically
- Multi Destinations: based on the Customer/user choices, further destinations can be used to send the messages
- Dedicated workflows based on User interaction
The available public APIs allow you to create a custom mobile application, develop a tailor-made back-office system or integrate with third-party software such as ERP, CRM or invoicing systems. A solid software architecture is critical to mitigating security risks and minimizing server downtime. Our team is ready to assist customers in designing a tailor-made solution.
Protocols and standards:
- OCPP is an application protocol that facilitates communication between electric vehicle (EV) charging stations and central management systems, even if they are from different manufacturers.
- The OCPI protocol was created specifically for the exchange of charging point information, enabling seamless communication between charging point operators and electromobility service providers, thus promoting scalable and automated roaming of electric vehicles.
- The OICP, established in 2012 by Hubject, a consortium of leading German automotive and energy companies, not only includes the protocol itself, but also provides ad hoc payment solutions and a contractual framework to facilitate electric vehicle roaming.
Innovery Notification Manager
A High level architecture and interfaces
INNOVERY GROUP: EXPERTISE AND EXPERIENCE
From 2019 following the Wise investments, Innovery aims to further accelerate its expansion by driving organic growth, leveraging existing relationships and building new relationships, and implementing an M&A strategy to develop products, services and markets internationally.
