Current event:
University Services - University Communications - How to renew communication of the university on digital channels for the benefit of the entire university community? University Services - University Communications / 11.10.2022. 16:00
Details and registration

Complete Hammy functionality

Communication


  • Omni-channel communications. E-mail, SMS text, Facebook, mobile app, archival, print, postal mail.

    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.

  • Message portal. Hammy attachments are not sent directly to the customer but can be downloaded after log-in from a web interface. 

    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.

  • Integration with an existing customer portal. Addig a notification e-mail to the base e-mail template. 

    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.

  • Dynamic configurability of e-mail parameters. (From address, Respond-to address, Bounce address etc.)

    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.

  • Managing bounced e-mails. XHeader or Sub-addressing. 

    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.

  • Configuration of automated bounce mechanisms. Workflow for handling bouced messages.

    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.

  • Managing multiple bounce addresses.

    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.

  • Handling response e-mail.

    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.

  • Automated settings for handling response e-mail.

    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.

  • Managing multiple respond-to addresses. 

    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.

  • White list.

    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.

  • Re-sending e-mail to custom address.

    Following successful communication, the message can be re-sent to a new e-mail address.

  • Setting sending priority, also at template and template group level.

    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.

  • Archiving without actual sending.

    A message ready to be send can be routed directly to the archive, without the actual sending operation.

  • Send API (SOAP XML,JSON, JSON API format over HTTP and Queue).

    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.

  • Tracking the opening and link usage in sent e-mail. Reporting. 

    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.

  • Scheduled sending. 

    Send operations can be initiated immediately or scheduled for a later time.

  • Batch sending, temporal distribution of sending. 

    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.

  • Scenarios - complext sending process design and reporting. (E.g. if e-mail not opened, send SMS text, if e-mail is bounced, send Facebook Messenger message.)

    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).

  • Scenario creation via drag-and-drop. Versioning support.

    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.

Content / general


  • Pre-defined and flexibly editable HTML templates.

    Pre-defined templates adhere to a company standard design. Flexibly editable templates cater for a high level of creativity for users.

  • Template management and versioning. HTML and plain text. Asset management, personalisation, markdown.

    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.

  • HTML frame around a template.

    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 built from custom fragments. Header, footer, further paragraphs.

    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.

  • Encryption of e-mail, de-coding interface for the customer. SMS and e-mail token for registration. 

    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.

  • Digital signature of e-mail.

    Ability to digitally sign the e-mail using the signature key from a defined key repository. This results in an authenticated message.

Content / attachment


  • Digital signature of PDF attachment, additionally signature image.

    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 of PDF attachment with custom password. Algorhythmic password generation at the level of templates, template groups or generally.

    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.

  • Authenticanted time stamping of PDF attachment from external TSA provider. 

    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.

  • Time stamp service. Authenticated time stamping using preferential Hammy pricing.

    Authenticated time stamping service is provided, using custom pricing, preferential for Hammy users.

  • Custom watermark of PDF attachment.

    PDF attachments can be watermarked, i.e. a custom image can be used at a custom position, with transparency defined.

  • Generating PDF from DOCX template. I.e. generating personalised printable document. Administrator front-end for template maintenance and approval. PDF generating service over API (SOAP XML, JSON, JSON API format over HTTP and Queue). 

    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.

  • Dynamic generation of form based DOCX template fill-in, producing unique PDF.

    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.

  • Receiving attachment from FTP and SFTP source.

    Files attached to the message can be received from various sources, such as service calls, file system, FTP, SFTP or a custom source.

  • Gathering attachment from DMS system.

    Files attached to the message can be gathered from the archive source of the insitution, in a integrated solution.

  • Calendar invite attachment.

    For invitation messages, a calendar ivite (ICS format) may be attached, which is fully parametrisable.

  • Defining temporal validity of attachment. 

    Non-personalised, static attachments can be sent, subject to custom parameters and temporal validity.

  • Attachment compression. 

    In case of several or large attachments, these can be compressed before sending.

  • Service API for signature and time stamping of PDF attachment (HTTP SOAP és JSON).

    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.

  • Checking PDF attachment before sending.

    A content check can be defined to PDF attachments. As a result, sending erroneous attachments containting irrelevant or sensitive data can be prevented.

  • Deferring sending in case of missing attachment.

    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.

Utilities


  • Performance metrics. Bandwidth, speed, periodic snapshot of system status.

    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.

  • Supervising functionality. Self-diganostics, localisation of error, stopping corresponding subsystem or template. Automated notification for administrator.

    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.

  • Notifying stakeholder clients of message status.

    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.

  • Regular sending of customisable reports.

    In addtion to base statistics, customisable reports can be sent at custom periodicity and intensity, to a defined audience.

  • Full-text search via Elasticsearch.

    Elasticsearch integration. As a result, full text searching of messages can be performed and search requests are carried out fast. Requires storage planning.

  • Periodic archival of database, custom deletion of obsolete data (GDPR).

    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.

  • Regulated access rights to functionality.

    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.

  • Regulated access rights for editing templates and sent message retrieval.

    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.

  • Creating and storing sent certificate for messages from SMTP server logs.

    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.

  • Managing multiple organisations with separated functionality and access rights.

    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.

  • Detailed listing of error queues (aggregated and granulat list), re-sending or deleting faulty items. Automatic deletion option.

    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.

  • Message template export and import.

    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.

  • Clustered operation, profiling, scalability over multiple dimensions.

    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 management of users. Active Directory integration for access rights and roles. In case of no Active Directory, using the Hammy user database.

    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.

  • Lifecycle function. Monitoring, tracking and logging of the full sending process. Adding events from external sources. 

    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.

  • High integrateability, unified API's (SOAP XML,JSON, JSON API format over HTTP and Queue).

    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.

Admin ui


  • Managing modules, queues, monitoring the run state. 

    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.

  • Querying communications history, search and export.

    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.

  • Viewing, exporting, e-mailing of statistics. Sending reports via e-mail.

    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.

  • Regulated access rights to administration functionality.

    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.

Extended / edm


  • 'Electronic Direct Marketing' module.

    Electronic Direct Marketing: additional Hammy module covering the business functionality of realising marketing campaign communications.

Extended / hddm


  • 'Hammy Digital Direct Marketing" module.

    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.

Extended / dms


  • Electronic document storage with full functionality and UI. 

    ’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.

Extended / tasks


  • Customisable task management and case management module, for handling incoming e-mail and resposes.

    ’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.

production | 1.2.5