Case Studies

Email Library Tool Increases Research Efficiency and Archives Claims Communication

Project at a Glance
RDA delivered a highly organized email library tool for a niche insurer that supports and achives policy and claims-related communication while increasing claims research efficiency.

About Our Client

RDA's client is a niche insurance provider and agency that underwrites coverage for concerts and night club venues. At the time of this project, our client managed hundreds of customers and thousands of claims each year.

Background

Our client retains email communication between itself and its customers as a reference and legal safeguard for claims disputes and other policy issues. The insurer lacked an efficient means to digitally archive, organize and recover email associated with its policies and claims. Prior to the RDA solution, our client had experimented with various approaches, including copying email messages into their system and even printing out and digitally scanning text messages.

Our client sought a customized solution that would enable customer service representatives to associate emails with specific claims and policies within their policyholder database. Ideally, the application would enable them to tie into their database while working within the Microsoft Outlook environment.

There is another problem with email from an insurer's business perspective: changeability. We all know how easy it is to spoof an email (i.e., changing some or all of its important attributes to make it look like something else altogether). Our client wanted a means to store received emails electronically that could support their evidence value to the same extent as if they were hard copies.

Solution Detail

RDA designed a solution that enables our client to save email documents as compound message files (including attachments) and associate them with specific policies and claims within an Outlook environment. The emails may be called up from within the context of our client's relational policies and claims database. The application enables service representatives to investigate claims and easily browse associated emails.

Our team took a two-fold approach to the problem. For integrated sending, we developed a set of class libraries that looked somewhat like Outlook and could interface to a server through a Microsoft Outlook Web interface. The libraries were separated into a presentation layer and a business layer. The presentation layer provided an integrated look and feel into which could be injected standard email components from the database. The user could then edit these in place before sending the email.

The business component was an email sending engine that took email document parts as parameters, together with user credentials on the server. Using https, it would connect with the OWA server and send email without the user's involvement.

For hardening an email, we delivered a wrapper on the Outlook function that saves an email to a Compound Document file, attachments and all. The Compound Document file is a Microsoft proprietary format deemed to be unalterable to change its appearance. We engineered a solution that allows our client to browse their email folders and choose an email to attach to a claim. The program then produces a Compound Document file and saves it to the database. Once saved in this manner, a compound document can be viewed in Outlook but cannot be altered.

Benefits

This project enhances our client's ability to grow and populate their database. All policy and claims-related email communication is retained for future reference.

In addition, by employing a unified storage process that bundles data within a highly organized system, service representatives are experiencing increased efficiencies in claims research.

Challenges

There were three major obstacles our team needed to overcome in delivering these solutions. The first was a lack of documentation uncharacteristic of Microsoft products. We used the WebDAV API to implement our communications with the server. While most functions were documented, the documentation was not easy to find. Many links were broken. Many key words that seemed like they should be links were just words.

The second challenge was our client's desire to avoid the security dialogs that pop up from Outlook when a user attempts to interface to it through the .NET framework. To work around this, the RDA team used the older Win32-based Mail API tools.

The third challenge was the fact that data from the Global Address Book and the Contacts folder is substantially different, even though it looks similar on the screen. The RDA team rewrote the application so that display data would match Outlook's format.