High-level product description
In the era of thick-client solutions transaction-like customer changing was the normal way of working. Transactional means the situation when the user makes multiple changes on a customer or on its services and presses the save button if everything is fine. Those thick clients were containing all the business logics and cared about all the changes from soup to nuts.
The thin-client age was facing the problem that the logics implemented in thick-clients were not possible to open into APIs, therefore they should be re-implemented. The other speciality of the thin-client world is that different channels are using different client solutions – and each of them are re-implementing the logics of account and service manipulations. Thus different implementations are working differently, therefore Multi-channel Sales and Customer Ccare becomes a nightmare, since no one can ensure that changes coming from different channels are equivalent anymore!
One more thing is that thin-clients are typically implements one change – one update logic, they are not capable to handle multistep transactional changes. This brought the loss of smart up- and cross-selling options and requires radical simplification in service and product portfolio. Radical simplification causes revenue loss and this is even worse than the loss generated by losing up- and cross-sales!
The closest solutions are the webshop carts, but they are not capable to handle changes of active (mean already bought and currently used) services, they prepared for selling new stuff. The result is for companies having continuous services on the market (telcos, insurance, finance, etc.) cannot get an appropriate solution from the IT solution landscape!
They need is a transaction engine, which is usable through APIs and solves all the problems mentioned above.
This is Reactor.
Reactor is the part of a transactional CRM solution family, which covers front-end solutions, human workflow management data caching of back-end applications plus order execution and provisioning modules.
Reactor has three main roles, that are described in the sub-chapters below. You will see Reactor as:
- transaction engine (T)
- rule engine (R)
- pricing engine (P).
Transaction based operation (T)
Reactor practically executes Product Offering manipulation transactions. These transactions are very similar to database transactions are: can be opened, may containing large amount of changes and can be committed or dropped (rollback) at the end.
The possible operations are starting from customer creation for greenfield sales processes and covers that simple tasks, e.g. updating a Product Offering parameter, like a call forwarding number.
To ensure data consistency, Reactor implements a locking mechanism on the accounts that are affected by a given change. The locking mechanism is “optimistic locking”, which compares the persisted account information at transaction start and finish. In case of no difference the transaction is submitted to order execution. This mechanism avoids early locking problems like stuck locks and disallowance of parallel usage of account in different transactions.
Rule-based business logic (R)
The business logic of Reactor is configurable using predefined business rule types, like precondition, exclusion, cardinality or moving together (and others). The rule-types are implemented and tested from performance and accuracy prospective in advance, therefore clients using Reactor only have to instantiate the appropriate rules based on a service modelling exercise. Instantiation will create rule instance like service “A” is a precondition to order service “B” or residential customer account type excludes service X to order and so on.
Rule segmentation (R)
In sophisticated business environments it simply happens, that thousands or rather millions of business rules exists to describe the appropriate and automatic service manipulations. Analysing many of so complex business situations we recognised that the rules and products may be segmented, where each segments will have only tens or maximum hundreds of business rules. Segments are defined by channels, business lines, account types, tariffs, product portfolio IDs — those dimensions, which are used in business operation in a given company to divide business to appropriate portions to keep the best focus on customers.
Segmentation has many advantages:
- helps to avoid unexpected side-effects of rule-set change (you define rules between services for a given portfolio but that rules may affect another portfolio elements as well)
- the low number of rules in a segment dramatically simplifies testing procedures
- it is possible to target a change to a given rule segment, while it is ensured that others will work as before
- the low number of rules ensures business operability and to keep the highest available performance.
Practically the engine is agnostic to the number of rules: if you have a hundred that’s fine; if you have some million that is also fine, there will be no difference in the user experience of executing transactions.
Segmentation keys are: business process, customer and subscription type, customer and subscription status, product portfolio, contract binding and tariff.
Customer hierarchy support (R)
The engine handles Product Offering manipulations in account and subscription level out of the box. Account level manipulations include both account level POs and batch kind changes to all subscriptions under a given account.
Utilising scores and balances (R)(P)
The engine is prepared to handle transactional balances and scoring information. Assuming that the environment using the transaction engine executes scoring and the result can be shared to the engine to be used as input of specific rules.
It is the same for balances, which can be financial or natural balances. An example is loyalty points handling. The environment of Reactor can share the loyalty balance of the account read from the loyalty system. Reactor is able to cover the price of a Product Offering from the loyalty balance assuming a PO configured to this logic. The engine will calculate the remaining balance after each loyalty related operations and will allow the ordering only that POs that have lower or equal loyalty price than the actual transactional balance.
Instalment handling (P)
Selling high-value hardware elements generates the demand of handling instalments. Reactor is capable to calculate instalments based on predefined business conditions, like initial fee ratio, maximum number and minimum amount of instalments and so on.
The transaction engine is designed to run in multiple instances. There are two ways of operations: stateful and stateless failover. In case of stateful failover the engine instances are sharing their transaction data through a central high-available memory database, therefore each instances can handle requests to any transactions. In case of stateless failover there is no transaction data sharing, each instance can handle only its own transactions, therefore the request routing uses sticky-logic by the transaction ID.
Low response time
The transaction engine is designed to interwork with high-performance online environments, including shops, IVRs or chatbots. These environments are not tolerating slow responses. The maximum response time of any operation using the engine is 1 second, while the expected response time is not expected to exceed 0.3 second.
The engine is designed to run large amount of complex transactions in parallel, executing thousands or millions of rule instances to serve them.
Transactions are handling customer personal data and other business sensitive information in many cases. Logging mechanism of the engine cares about to clean-up of aged logs and to skip logging of sensitive data, like activation passwords related to a service.
Transparent multichannel access with channel authorisation
The engine can be used by different channels in parallel, with the configurable limitation of authenticating and authorising channels for operations. The authorisation function ensures that there will be no illegal usage of the engine, meaning that there are no illegal changes in transactions.
The multichannel support provides another important opportunity: channels can forward an open transaction between each other. For example, a chatbot starts to sell something new to an identified customer but at the end back-office administrator has to close the order because of various reasons. In this case the chatbot has to send only the transaction ID into a back-office queue and the agent using his own UI will see the same stage that the bot reached by the customer.
Transaction aging (T)
To keep high-performance orphan transactions are cancelled automatically. The aging period is configurable by a system parameter adapting the engine behaviour to different operating environments.
Data model specialisation
The engine works with generic Product Offering items, which are representing the market products that are sold or manipulated on the given market. The main design pattern was to have as many generic capabilities as possible. The specific product types, like a telecommunication service tariff or a stockable hardware items have to have their own specialities. They created using “specialisation”, means they inherit the generic capabilities and extended to their defined extras, like stock check for the hardware items.
The engine is configurable through a reference data store, which contains all product offering details and rule instances controlling their behaviour. Reference data is cached by the engine at starting and in addition by a cache refresh mechanism.