Managing multiple delivery channels. The most significant ones are e-mail, SMS text, Facebook and print. The structure of channel management is standard, so further channels (e.g. mobile app) can be easily implemented and customised.
Customer portal functionality is provided. This serves the purpose of the customer not receiving sensitive information via e-mail. Only an optional notification is sent. The customer then logs in to the password protected zone of the portal where they can securely access their messages and documents as well as send messages back to the institution.
The system can be configured to send a notification in the place of the full e-mail which is a significant feature to protect sensitive data. This is also the basis of a customer portal integration whereby the customer only receives the notification that they have a message, then they can log in to the customer portal to access the full message which may contain attachments and meta-data as well.
Channel parameters can be defined dynamically, even at the send event level. This covers sender data (e-mail address, name or telephone number in case of SMS text), the response channel, the communication point definitions (SMTP server, SMS gateway etc.) and further settings.
Undeliverable e-mail (’bounces’) are registered for futrher processing. Several types of bounces can be identified, based on sub-addressign and extension headers. In the former case, the ID is injected into the return path, in the latter it is hidden in the message header.
There are several reasons for undeliverable e-mail (’bounces’). Some reasons may be temporary while others are permanent. A rule set can be applied, allowing re-sending in case of certain errors. The total number of tries as well as the time elapsed between re-tries can be set.
Multiple ’bounce’ accounts can be set. Bounces from different templates can be routed to different accounts. This way bounces can be separated based on message content.
Incoming e-mail from customers is registered and saved into a safe database. This protects customer e-mail from being modified at a later stage.
Response e-mail is processed and routed to a customer service account, based on a rule set. Configurable extra data can be added to the responses, in order to support post-processing.
Multiple respond-to accounts can be defined over the base settings. Even responses to different templates can be routed to different accounts. This way responses can be separated based on message content.
A permissive ’white list’ can be defined, whereby only the listed customers can receive messages from the system. This is significant in a testing period. Textual identity as well as regular expressions can be applied to defined the names.
Following successful communication, the message can be re-sent to a new e-mail address.
Message priority can be set. E.g. business correspondance, such as policies and invoices can enjoy higher priority while the priority of marketing messages can be set lower. The system delivers high priority messages first, low priority messages later. Priorities can be configured for templates and template groups.
A message ready to be send can be routed directly to the archive, without the actual sending operation.
Services can be access via standard interfaces such as HTTP, HTTPS or Queue channels. Requests are received via Soap XML or in Rest JSON/JSON API format.
Customer activity is tracked. The system registers message opening and link click-through. Analytics and reports can be defined and sent vial e-mail too.
Send operations can be initiated immediately or scheduled for a later time.
Large volume sending can be spread temporally. A batch volume can be set, as well as the time elapsed between batches can be defined. E.g. one million messages can be segmented into ten send events, each containing one hundred thousand messages, with half an hour elapsed between them.
For a template, a complex sending scenario can be designed. This is built so that cutomer actions (or lack thereof) trigger further steps, such as sending further messages or waiting/holding out. One example is: an important invoice is sent via e-mail. In case it bounces, the customer is notified via SMS text. Or: an important invitation is sent. When the customer opens the message, a thank you note is sent via the same channel or another one (e.g. via Facebook).
Complex sending scenarios can designed using a drag-and-drop interface. An overview of existing scenarios is available and scenario designs in use can be maintained.
Pre-defined templates adhere to a company standard design. Flexibly editable templates cater for a high level of creativity for users.
Sophisticated template management. Templates may be optimised for different channels. Templates can be versioned. Template text may contain dynamic data as well as branching, loops and list processing. In the case of e-mail, HTML, plain text and markdown formats are supported.
A frame can be added to template. Just as in the body, text can contain dynamic data as well as branching, loops and list processing in the frame. Frames allow single point maintenance and easy re-use of generic content data as well as headers and footers.
Templates can be generated using fragments. Fragments may cover headers, footers or further paragraphs, in a recursive manner too. Fragments may contain dynamic data as well as branching, loops and list processing.
E-mail encryption is shortly summarised as the following. The content sent to the customer (complete with attachments) is encrypted using an encryption key. The customer receives this encrypted content to their mailbox. The encryption key is never stored, but it is sent to the cusromer together with the message. (Only the private key of the customer is stored.) As a result, high level security is achieved, whereby only the customer themselves can decode the message. When opening the message, the customer is routed to a log-in screen, which facilitates single-step or two-step authentication. (This is a configurable choice.) Getting to the content, the customer may store the message content and attachments. Any device can be used by the customer for decoding and viewing, of which the institution is notified for further analytic and reporting purposes.
Ability to digitally sign the e-mail using the signature key from a defined key repository. This results in an authenticated message.
Ability to apply digital signature to the PDF attachment. The signature key is applied from a defined key set. As a result, the authencity of the PDF document attached to the message is secured.
Encryption in Hammy follows the guidelines of the Hungarian National Bank. The PDF file sent to the customer via e-mail, containing sensitive data, is encrypted using a password known to the customer. As the customer knows the password (e.g. birth date, ID number, telephone number, customer ID, contract ID or a combination of these, etc.), and this can also be referred in the e-mail text (with appropriate masking), there is no requirement to initiate a full password exchange process (e.g. via SMS text). This is a cost effective and customer friendly way to ensure that no unathorised person can access the PDF content. A defined algorhythm can also be used to create the password, which can be associated with a template or template group or applied generally.
In addition to digital signature, the PDF afttachment can carry an authentic time stamp, in case a provider is available. Time stamping is done via the standard TSA protocol.
Authenticated time stamping service is provided, using custom pricing, preferential for Hammy users.
PDF attachments can be watermarked, i.e. a custom image can be used at a custom position, with transparency defined.
A personalised printable document format is created, based on a DOCX template. The DOCX template may contain dynamic data, branching, loops, lists etc. The template may be built from fragments, just like any communication template. An administrator interface is provided for maintenance and approval processes. Generating PDF’s is available via API (SOAP XML, JSON, JSON API) as well as HTTP and queue.
An easy-to-use and customisable interface is provided for printable documents. It allows for setting values to DOCX template variables based on their types. A PDF preview is also provided. Finally, the send operation can be initiated. Variables in the DOCX template are pre-configurable, i.e. therir type, display format and compulsory nature can be set. This is an ideal solution to create an interactive agent interface for generating and sending unique customer messages.
Files attached to the message can be received from various sources, such as service calls, file system, FTP, SFTP or a custom source.
Files attached to the message can be gathered from the archive source of the insitution, in a integrated solution.
For invitation messages, a calendar ivite (ICS format) may be attached, which is fully parametrisable.
Non-personalised, static attachments can be sent, subject to custom parameters and temporal validity.
In case of several or large attachments, these can be compressed before sending.
Applying digital sigtaures and time stamping to PDF’s can be done not only as part ot the send process, but as a service, in batch. As such, these documents are not part of the communication process.
A content check can be defined to PDF attachments. As a result, sending erroneous attachments containting irrelevant or sensitive data can be prevented.
In case an attachment is defined for the message but it is not available (via file system, FTP, SFTP, DMS, etc.), the system will park the message instead of sending it immediately. The availability of the attachments can be re-checked at configurable intervals. In case a defined time limit is reached, sending attempts are aborted.
An integrated measurement tool serves for performance monitoring. (Metrics) Bandwidth of queues and modules can be measured and a periodic snapshot can be provided of the system status.
In case of an internal technical error, a machine supervisor process detects and localises it in the specifc configuration. The corresponding sub-system is stopped for a given time, or in case the source of error is a template, this template is blocked. An e-mail notification of these events is sent to system administrators.
External systems can be notified of the message status. This notification contain the status change, i.e. successful or erroneous sending, bounced, messages on hold or archived, etc.
In addtion to base statistics, customisable reports can be sent at custom periodicity and intensity, to a defined audience.
Elasticsearch integration. As a result, full text searching of messages can be performed and search requests are carried out fast. Requires storage planning.
At periodic intervals, the contents of the active production transactional database are backed up into a passive, archival database, in order to reduce the production load. The data set to be backed up is configrable and the messages may be permanently deleted at well. Such configurations are usually linked to templates. Legal ramifications may define the to-be-archived data set.
User interface functionality can be linked to granular authorisation levels. Functionaliy accessible to individual users, e.g. viewing and modification of settings can be set.
Editing and listing of templates as well as messages based on templates is subject to authorisation. Templates or template groups can be associated with users and user groups.
A certification PDF document is created for sent e-mail, based on the STMP server log. This contains the parameters of the sent message as well as the subject, body and meta-data. In addition, the sending data from SMTP server log is provided. This PDF can be set up to be sent to the archive or saved to the file server.
A single Hammy application can service several organisations within the institution. Users are associated with one or several organisations. When logged in to Hammy, users can access only work with the settings, templates, messages, campaigns and reports of the organisations that they belong to.
Erroneous items are routed to an error queue. Error queues can be listed, the error reason viewed and as a result, an informed decision can be made whether to try re-sending or remove the item from the sending process. Automated re-sending or removal can also be configured.
Communication templates can be exported from the system in an interchangeable format. These are also ready to import into another solution. As a result, templates are easily portable.
Sophisticated maintenance functionality is at hand. Full monitoring of the system status is provided. Vertical and horizontal scalability is available. Hammy is built from distributed and loosely coupled modules which communicate with each other via queues. Individual modules can be started and stopped, run states and saved states are differentiated. For vertical scaling, new instances can be launched (e.g. profiled for specific tasks). For horizontal scaling, multiple threads of modules can be launched.
Full user magement via Active Directory integration is provided. Roles and authorisation for the Hammy user interface can be defined in AD and collected from there. Another option is to apply a custom user database and register Hammy users, roles and authorisations there.
The whole communication lifecycle is tracked using an event-driven logic which starts with the communication request and lasts till the closure of the communication. Events can be received from external sources and systems as well as internal processes. As a result a full view of batch communications requests is provided.
Hammy services are available via standard interfaces. I.e. HTTP, HTTPS or queue channels or Soap XML or Rest JSON/JSON API format requests are supported.
Sophisticated maintenance functionality is available on the administrator interface. Full system status monitoring in provided, the status of vertical as well as horizontal scaling is displayed. Hammy is built from distributed and loosely coupled modules which communicate with each other via queues. Each module is reponsble for a well defined task and may be run over multiple instances. The run state as well as the queue contents are displayed. Items may be moved from queues and tracked via the administrator interface.
Full customer history can be displayed. Filtering is provided for listing messages and events, i.e. outbound and incoming messages, clicks, subscriptions, logging in to the customer portal, viewing encrypted e-mails. Events can be exported and reported on. Actual sent messages can be viewed, meta-data listed and attachments downloaded. In case of bounces the bounce notification can be viewed and the reason analysed.
Messaged sending is tracked and recorded. These statistics can be viewed and exported as well as sent via e-mail, complete with system configuration data. Further reporting can be customised.
Administrator interface functionality can be linked to granular authorisation levels. Functionality accessible to individual users, e.g. viewing and modification of settings can be set.
Electronic Direct Marketing: additional Hammy module covering the business functionality of realising marketing campaign communications.
Digital Direct Marketing: additional Hammy module covering the business functionality of supporting the full lifecycle of marketing campaign design and delivery, i.e. planning, targeting, communications, tracking and measurement.
’Doky’ electronic document management solution. Standalone functionality integrated with Hammy. Managing documents and versions, corresponding to the business hierarchy. Storage of meta-data, full searchability and integration with enterprise systems.
’Hammy Case’ solution for case management and task management. Standalone functionality integrated with Hammy. Supporting the association of tasks, activities and deadlines with messages. Managing deadlines.