Column 2

The second half of the morning at ISIS Papyrus was a pair of sessions on document output and document input, or as the session titles put it, “unified print, web and mobile output management” and “scan to extract to process”. The first was a great deal more information on yesterday’s session on correspondence generation, and you can check out their website for more information on the features and functions.

The second session, on document capture, started with business drivers for capture and scanning, particularly the link from capture to process. A lot of organizations are doing capture to archive, but a smaller percentage are using recognition technologies (classification and extraction) or triggering processes from the documents. Interestingly, a much larger percentage are using document classification (i.e., what type of document is this) but not data extraction (i.e. what customer-specific information is on the document); there’s a big ROI just in document classification without additional recognition since that can be used to automatically route documents to the right department for handling.

They handle a variety of input channels and devices: scanners (including check scanners), MFPs (“Mit Netzwerkanbindung”, according to the slides ), fax, email, camera phones, social media and file import. I had a demo yesterday of their recognition and extraction capabilities, and it can be applied to both structured forms and freeform documents. A typical capture path includes steps for rearranging, splitting and merging (often for fax documents, over which there is less control on the input), then document classification, automated extraction and validation, then manual verification and correction. In this way, they provide the same functionality as products such as Kofax or IBM Datacap.

Document classification can be based on layout (fixed format), keyword (text or barcode) or text-based (phrases), and their capture design environment allows for learning by example to create any of these. 2D barcodes (which may have been generated by their outbound correspondence module) can be identified and used to match an inbound document to an existing case.

There are a number of administration and monitoring capabilities to track how many documents/batches have been captured and where they are in the processing queues.

They have a number of customers that are capture only – this, in addition to correspondence generation, are two of their key use cases – but provide greater added value if the capture process leads directly into distribution and case creation/management.

We’re running 30 minutes late and it’s right before lunch, but everyone is sticking around to hear Ignatius Chang, EVP at China Trust Commercial Bank, talk about their initiative for statement e-delivery. Based in Taiwan, they are in an overcrowded financial services market, and technology has become a competitive differentiator for them in customer retention through superior service. They have about 5 million credit card holders, and send out over 2.5 million statements per month. These statements aren’t just a statement, however: they include targeted promotional information and offers for other products and services in the same document.

Their move to e-delivery was driven by some basic business goals: they wanted to reduce print and post costs by moving customers to e-statements, but maintain the personalized marketing and visual appearance of the printed document without generating a PDF. They wanted a common document design and handling process for both paper and electronic, although electronic required additional features such as secure encryption and support for mobile devices. Since the statements included marketing campaigns, they wanted to be able to track the campaign response rate, since this contributed to their return on investment (in addition to the cost reduction when moving to e-statements).

They are only partway along their journey with the Papyrus platform, so some of this described future plans rather than current reality – it will be interesting to see how they achieve their goals as they continue to implement in the future.

In the previous session, we heard a lot about the ISIS Papyrus correspondence generation capabilities, but it’s important to look at response management, that is, closing the loop with inbound and outbound mail. This has to be considered in two different scenarios: an inbound customer interaction (paper, email, telephone, social media) triggers an internal process that results in a response interaction; or an outbound document solicits a response from a customer that must be matched to the outbound request. Response processes can be fully automated, manual, or automated with user intervention, depending on the degree of classification and content extraction that can be done on an inbound document. Not only does it handle the entire response management process, it provides analytics, such as campaign responses.

Their capture components include classification based on layout, keywords and/or barcodes; and data extraction from fixed forms or freeform documents. I’m not sure if this is their own recognition software or if they OEM in someone else’s (I suspect the former, since they seem to be doing a lot of innovation in-house), or how the accuracy and throughput compare with market leaders such as Kofax and IBM Datacap.

Once the document is captured, classified and the content extracted, a response letter type can be selected automatically based on business rules or manually by a user, then completed either automatically based on the content of the inbound letter, or with user assistance.

There are specific social media capture functions, such as the ability to track a Twitter hashtag, then analyze the sentiment and open a case directly from a tweet. If the user is identifiable, it can cross-reference to customer information in a CRM system, then present all of the information to a user to follow up on the request or complaint. This is exactly the sort of scenario that I imagined happening internally at Zipcar during the interaction that I described when talking about linking external social presence to core business processes.

If you consider the business scenario, it’s a real winner for handling inbound customer correspondence. First, an inbound document is received, analyzed and routed based on the content, including things such as looking up or extracting customer information from other systems of record. If some manual intervention is required for the response letter, a CSR is presented with the inbound letter, the generated outbound letter, customer information from other systems for context, and instructions for completing the letter. Inbound correspondence can be anything from a paper letter to a tweet, while the outbound can be the channel of choice for that customer, whether paper, fax, email or others.

Annemarie Pucher, CEO of ISIS Papyrus, discussed having a business communication platform for handling personalized content. Rather than having multiple systems that deal with content – ingestion, analysis, processing and generation, multiplied by the number of interaction channels – a single platform can reduce the internal efforts to develop content-centric processes, while presenting a more seamless customer experience across multiple channels. This is particularly important for personalized outbound documents, whether transactional (e.g., statements), ad hoc (online presentment), or as the result of a business interaction (e.g., contracts), since the customer needs to be able to receive the same information regardless of which interaction channel that they choose.

She discussed how their platform provides fully personalized outbound correspondence based on composing documents from reusable elements rather than a simple mail merge approach. The building blocks may be sections of text, graphics, 2-D bar codes and other components, which can then be assembled in different ways based on rules that consider the customer information, the geographic region and other factors. Different language versions of each component can be created. The document assembly can access business information from other systems through a variety of adapters, and interface with different input and output channels. Business people can create and modify the building blocks and the overall document template, allowing them to change the layout and the dynamic content without IT intervention, although IT would be involved to set up the adapters and interfaces to other systems and services.

For interactive correspondence generation, such as what would be done by a customer service representative in response to an inbound call, they provide in-document editing of the dynamically-created letter. This allows the user to type in information directly and select which sections of the document to include, while ensuring that the predefined content and rules are included in the format required. There can be a complete workflow around interactive correspondence generation, where certain changes to the content require approval before the document is sent to the customer.

Regardless of whether the document is created interactively or in batch, that single document can be rendered to multiple output channels as required, including hardcopy and a large variety of online formats. This can include functions such as pooling for combined enveloping (something that I wish my brokerage could learn, rather than sending me multiple confirmations in multiple envelopes on the same day), confirming that a printed document was sent, and handling returned paper and electronic mail. Supporting CMIS allows them to store the documents in other content repositories, not just within their own repository.

We finished up with a demonstration of creating building blocks in their Document Workplace, then assembling these into a document template. The workplace is similar in appearance to Microsoft Word from a text formatting standpoint, making it easy for business people to get started, although there’s quite a bit of complex functionality that would require training. Although no technical skills are required, it does require some degree of analytical skills for designing reusable components, handling variables, and understanding document assembly parameters, so may not be done by the average business user.

I haven’t spent a lot of time reviewing correspondence generation capabilities, but it’s something that comes up in many of the BPM implementations that I’m involved in, and typically isn’t handled all that well (if at all) by those systems. In many cases, it’s a poorly implemented afterthought, performed in a non-integrated fashion in another system, or becomes one of those things that the users ask for but just never receive.