AUTOMATED BUSINESS TRANSACTION CREATION FOR EMAIL SYSTEM

A system for automated email task management comprising an email server, a workflow server, a document storage server, and a computing device having non-transitory memory storing email client software, workflow client software, and a bridging software. Upon receipt of an email, the bridging software determines that the email contains instructions requiring initiation of a workflow, the bridging software automatically converts security credentials from a first security scheme used by the email client software to a second security scheme used by the workflow client software, and the bridging software provides a user interface that allows a user to automatically initiate a workflow in the workflow client with one or more data elements of the instructions prefilled in a graphical user interface of the workflow client software.

FIELD OF INVENTION

This application relates to methods and systems for modifying user interfaces in communications software, document management software, and business workflow software, and providing a framework and software library to securely automate the storage of and implementation of a variety of incoming consumer indications of intent.

BACKGROUND

In a number of commercial industries, customer service representatives spend a great deal of time receiving orders from customers to purchase goods and assets. They also perform a number of other account transactions such as updating account contact information, changing the beneficiary of an account, or updating permissions to add or remove named account owners or authorized users.

Customer service representatives save information regarding customer orders for company record-keeping purposes and, because the requests may come in a variety of non-standardized formats, including handwritten requests, older and deprecated forms, or emails that textually describe the customer order and rely on interpretation by a representative to be implemented.

Customer service representatives often have to transcribe customer orders into a computerized system unique to a particular company, slowing down fulfillment of the order and introducing the possibility of error in the order, or error in where the original document from the customer is stored, if records regarding authority for a transaction need to be consulted. Task switching from reading a customer communication, to entering information in a separate interface, to saving documents using a third interface causes increased opportunity for user error and less efficiency as the mind reorients itself to the separate tasks.

As a result, there is a need for automated systems that reduce user error, make customer service more time-efficient and responsive to customer needs, and improve compliance with data retention requirements.

SUMMARY OF THE INVENTION

A system is disclosed for automatically reading the contents of emails and attachments to determine customer intent, manage document storage to comply with record-keeping requirements, initiate a new business workflow to satisfy the customer's intent, and prefill as many elements of the business workflow as possible.

A system for automated email task management is disclosed, comprising at least an email server, a workflow server, a document storage server, and a computing device having non-transitory memory storing email client software, workflow client software, and a bridging software. In the system, upon receipt of an email by the email client software, the bridging software determines that the email contains instructions requiring initiation of a workflow in the workflow client software, the bridging software automatically converts security credentials from a first security scheme used by the email client software to a second security scheme used by the workflow client software, and the bridging software provides a user interface that allows a user to automatically initiate a workflow in the workflow client with one or more data elements of the instructions prefilled in a graphical user interface of the workflow client software.

Additionally, a method for modifying a plurality of existing graphical user interfaces (GUIs), is disclosed. The method comprises adding, via a plugin and to an email client GUI, a command to obtain, from an email accessible by the email client, instructions requiring initiation of a workflow in a workflow client. In response to triggering the command, software used to perform the method automatically identifies, from the instructions, one or more data elements necessary to initiate the workflow in the workflow client; automatically stores, in a document management server, a representation or copy of the instructions; automatically initiates a workflow in the workflow client; and automatically prefills, in a GUI of the workflow client, one or more data fields with the one or more data elements.

A method of accurately initiating workflows in response to a received indication of intent is also disclosed. The method comprises receiving a digital communication comprising a digital attachment via communication client software, automatically determining that the digital attachment contains instructions requiring initiation of a workflow in workflow client software, and automatically obtaining one or more data elements of the instructions from the digital attachment. Then, the system automatically converts security credentials from a first security scheme used by the communication client software to a second security scheme used by the workflow client software and provides a graphical user interface that, when engaged by a user, initiates a workflow in the workflow client with the one or more data elements of the instructions automatically prefilled in a graphical user interface of the workflow client software.

DETAILED DESCRIPTION

FIG. 1depicts a computer system for receiving and acting upon communications from a client.

With reference now toFIG. 1, a client100may use a client computing device101to receive one or more forms for requests102from a document storage server103. The client computing device101may be, for example, a customer's desktop computer, laptop, tablet, mobile phone, or any other computing device. Client computing device101is connected to representative computing device108, and may be connected to the document storage server103and/or to security credentials server104via network107. Representative computing device108may be connected to one or more of document storage server103, security credentials server104, workflow management server105, and business rules server106via network107. The representative computing device108may likewise be a desktop computer, laptop, or other computing device.

When reference is made throughout this specification to client computing device101or representative computing device108being used to perform an action, the actual processor and memory used to perform the action may be located in a remote device, with the computing device101or108being used as a “thin client” or “dumb terminal” that provides a local graphical user interface for software running on a remote server, allowing client100or representative109to trigger actions on the remote server via commands issued at client computing device101or representative computing device108, respectively.

In some embodiments, network107may be a private network for representative computing device107and servers103-106, with a gateway that prevents communication between the client computing device101and those servers103-106; in other embodiments, the network107may simply represent a cloud based server infrastructure to which both client computing device101and representative computing device108may connect.

In a preferred embodiment, the form for request102is stored in the portable document format (PDF), tailored by the service provider to correspond to a specific workflow or set of workflows, with fillable form fields to standardize customer input, potentially enforce data validation rules (such as, for example, an amount being a number rather than a string), and make machine extraction of the form data simpler.

In alternative embodiments, the request form may be a PDF without fillable form fields (such as a converted scan of a pre-made form tailored to one or more workflows), an alternate type of pre-created form (such as in Microsoft Word™, another office open extensible markup language (OOXML) file format, another word processing format, or a desktop publishing format), or even a plain text format.

In some embodiments, the request102may be a PDF file or other file that is encrypted, either according to a security feature within the file (such as a password-protected PDF function) or due to encryption of the file's binary representation itself. If the request102is encrypted, a security server104may be used either to obtain a public key that should be used for the encryption process

Similarly, in some embodiments, the request102may, before or after being filled out or created by client100, be “zipped”, archived, compressed, etc. into an intermediary format that requires unzipping, unpacking, decompression, etc., as appropriate.

In an alternative embodiment, the request form102may be generated by the client100himself, either using word processing or other document preparation/desktop publishing software.

In yet another alternative embodiment, the request102may be created by taking a photograph or scan of a printed-out form or even a blank sheet of paper upon which the client100has handwritten, typewritten, or otherwise added information.

The client100may cause the request102to be attached to an email message104and transmitted to a customer service computing device105. In some embodiments, multiple requests may be attached to a single email, and in some embodiments

In alternative embodiments, request102could be instead attached to a text message (if client computing device101and representative computing device108are both mobile phones) or to any other data format for transmission to and receipt by a communications client on the representative computing device108.

After causing the request102to be transmitted via network107to representative computer108, customer representative109may use the representative computer108to open the request102and review what service client100intends to have performed.

Representative computer108may be connected via network107to a document storage server103(for the storage and retrieval of blank forms for use by clients or filled-out forms for storage while being processed and for records-keeping compliance), a security credentials server104(for the storage of passwords or keys for encryption and decryption of documents, or login information and credentials for various domains to which the client or representative may have access), workflow management server105(for storing information regarding in-progress or completed workflows), and business rules server106(for storing information regarding policies that must be followed by the client and representative, such as what information must be provided along with a client request to be honored, or what types or levels of representatives are permitted to execute a particular workflow type).

AlthoughFIG. 1displays four servers103,104,105, and106, the functionality that is ascribed in the various embodiments of this disclosure to one of these servers may be divided among multiple servers (such as, for example, having a first document server to serve one kind of document, and a second document server to store a second kind of document), or consolidated into a single server performing multiple roles (such as, for example, a single server that acts as both a workflow management server and a business rules server).

FIG. 2depicts a method for responding to a client's request by initiating a workflow.

With reference now toFIG. 2, when the representative109begins using the representative computer108, it is first determined whether the representative has rights to access emails or other communications sent by clients to an organizational domain (Step200). If the representative lacks these rights, the process ends with the representative excluded from using an email client to access the clients' emails. Whether the representative has rights may be determined by checking a provided username and/or password against a database stored on security credentials server104or a similar server for the organization.

If the representative does have the rights, the representative may be issued (and may have stored on the computer for the duration of the session) a token, cookie, or other security credential (Step201). In a preferred embodiment, Kerberos may be the security scheme used by the organization for controlling access to various software, including the communications client described below. In alternate embodiments, other security schemes may be used to enforce permissions.

If credentials are provided, the representative is provided with an email client user interface to access the set of client communications to which the representative is entitled (Step202). In a preferred embodiment, this interface may be provided by Microsoft Outlook™. In other embodiments, the interface may be provided by another client, such as Mozilla Thunderbird™, or by a webmail interface rather than a desktop program.

While the representative uses the communications client, the client continually checks for new incoming messages (Step203). If no new message is found, the client may wait for a period of time and check again.

If a new message is received, a plugin added to the communications client may check to see if the body of the message or its attachments contain a client request for the representative to undertake some action on the client's behalf (Step204). The plugin may utilize an application programming interface (API) of the communications client to add additional functionality to the client, as described throughout the disclosure below. The determination may include determining that at least one attachment to an email is a standard form used by the organization or determining that a form, while non-standard, matches the fields of a particular form used by the organization (i.e., the form lists at least some same data elements, such as account number or name, even if in an incorrect order or placement). The determination of the user's intent and the reason for which they have sent the form may be as simple as verifying that the form is an organization-provided form that contains a predefined title, text, bar code, QR (quick response) code, serial number, or other unique identifier. If the form is non-standard, in contrast, such as one created by a user, the determination may require attempting to “scrape” one of more text fields from the file and determining what significance they have to any possible workflow, or even using optical character recognition (OCR), natural language processing, or other artificial intelligence techniques to determine which form type is a most likely match. If the client has handwritten, typewritten, or taken a photograph of scan of a request to send in with the message, OCR, natural language processing, or similar techniques may be required for an automated system to have any hope of determining the client's intent in sending the form. An archived or encrypted form may require software to automatically unpack or decrypt the file, to obtain decryption credentials from a credentials server, or to prompt the user for decryption credentials.

Once the determination of the client's intent is made, the plugin may check whether the representative is entitled to act upon the client intent (Step205). In some embodiments, particular workflows may require that the actor who completes a given workflow be, for example, a manager in the organization, an executive, or at least of some level within a particular organizational hierarchy. Other workflows may allow any person within the customer service arm of the organization to act on and fulfill the request. Various rules regarding permissions to perform a particular workflow may be stored in business rules server106and retrieved regularly by the plugin to allow changes in representative permissions and other business rules without having to reinstall the plugin or modify any software running on the representative computer.

If the representative is entitled, the representative may need to obtain separate credentials for a workflow management software that is used to update information (such as the identity and contact information of a client, the owner of an account, the beneficiary of an account, etc.) and/or take action in response to a client request (buy assets/sell assets/transfer assets, etc.) (Step206). In a preferred embodiment, the workflow management software may use SiteMinder™ to manage permissions. In other embodiments, any number of other security schemes may be used, including other Single-Sign On solutions, Kerberos, or other security methods.

To simplify the automation of workflow management and creation, the system may comprise code to automatically convert a first security credential or token in use by the communications system to a second security credential or token to be used by the second system. A sample body of computer code for accomplishing this transfer from one credential scheme to another in a preferred embodiment can be found in Appendix A, below. In other embodiments, the user may manually enter a password to log in to the workflow management software, or if a single sign on solution is used by the organization, the credentials already provided when using the communications system or other software on the computer may already allow access to the workflow management software.

Once the representative has obtained or entered proper credentials for the workflow software, a new workflow may be initiated by the representative (Step207). In a preferred embodiment, this can be initiated from the communications client itself, using the plugin, if the plugin has already identified the workflow type and relevant documents, and obtained any required credentials for accessing the workflow management software. An interface for confirming information from the relevant documents and initiating the workflow is shown in greater detail below, withFIGS. 3 and 4.

Once the workflow has been created, the plugin (or other software in communication with the plugin, such as an application programming interface (API) of the workflow management software) may populate one or more fields of the workflow management software (Step208). The fields may be, for example, the client's name, account number, workflow type, the files documenting the client's request, and any other values associated with the request (such as a dollar amount to purchase, a number of shares to sell, a number of units to buy, etc.). The values to be entered in the fields may be determined by scraping them from files provided in the attached documents.

In conjunction with actually creating and executing the workflow, the files that document the client request should be saved in the document storage server103or another database (Step209). By automating this step through action of the plugin or the plugin's invocation of an API, the risk of the representative saving the documents in an incorrect folder, misnaming them, or associating them with an incorrect client can be eliminated, since the plugin may store information regarding exactly where the documents should be saved to maintain the proper associations with clients and ensure that a search functionality can find the documents.

In various embodiments, a number of the steps of the method described may be performed in a different order or in parallel. For example, saving the document(s) (Step209) may occur prior to initiating the workflow (Step207), if documents should be saved regardless of whether they are eventually associated with a workflow; in another example, workflow credentials could be obtained (Step206) immediately after message security credentials are (Step201), with a view towards more quickly initiating a workflow once a suitable communication is received.

FIG. 3depicts an example graphical user interface for initiating a workflow from an email client.

With reference now toFIG. 3, while viewing an email304with attachments using an email client300(such as Microsoft Outlook™, or another commercial or open source email client capable of installing plugins to provide additional functionality, including Mozilla Thunderbird™), the plugin software may detect the attachments and cause a button (or tab, or other contextual menu)301to appear, become colored instead of “grayed out,” flash, become animated, or otherwise change a visual property to indicate that a user may interact with it.

In alternative embodiments, client300may, instead of being an email client, be a client for a different messaging system, such as mobile phone texting or in-browser software for an online social network.

When button or other user interface element301is interacted with while viewing email304, graphical user interface302(which is displayed in greater detail inFIG. 4, below) may appear within the client. Graphical user interface302may be a pane in a multi-pane environment, a separate window, or an interface that may be docked as a pane and dragged as a window according to user preferences in a modern drag-and-drop interface. Graphical user interface302is used to initiate a workflow using the documents attached to email304.

FIG. 4depicts in greater detail the user interface for workflow initiation incorporated into the client depicted inFIG. 3.

With reference now toFIG. 4, within graphical user interface302may be branch and account selection boxes402, workflow type selection403, form name selection404, file selection405, and initiation buttons406. Client information407may also be displayed, as gathered by the plugin by using information from the email's sender header to lookup stored client profile information in a central client database stored on server104, server105, or another database server.

In some embodiments, a user may have to select each of the appropriate options in inputs402,403,404, and405. In some embodiments, one or more of these inputs may be pre-filled, such as by code running in the plugin determining either from an attachment's filename or from the contents of the file what the appropriate value for that selection should be. The selection by the plugin code might prefill a value only if it is certain of the proper selection (e.g., if the filename is an exact match with an expected filename for a certain document type, or if an attached file is a Tillable form matching a form provided for a specific use) or alternatively, the code might prefill a value based on a “best guess” from analyzing the filename and file contents (e. g., if the filename most closely matches a certain file format, or if the fields and words in a non-standard form indicate above a probability threshold that the document was meant for a specific workflow). If neither certainty nor a sufficiently certain guess are available based on the plugin's analysis, the inputs may remain empty for a user to fill in.

Tabs401may be provided to allow a user to select a different and more convenient scheme for entering or confirming data for workflow initiation. In the example embodiment depicted, tabs for “single,” “multi” (i.e., “multiple”) and “auto” (i.e., “automatic”) exist. Single mode may allow a user to initiate a single workflow (which is chosen in input403) based on a single document (which is chosen in input405). Multiple mode, in contrast, may allow a user to initiate more than one workflow at a time, by providing a button or other interface element that, when clicked or otherwise engaged by the user, adds additional instances of inputs403,404, and405as desired by the user. In “automatic” mode, the plugin may analyze a unique identifier in the file attachment (such as, for example, a QR code imprinted on a form) provided only to a single client beforehand and only on a single form, from which the purpose of the form can be known with certainty. In such a case, the inputs402,403,404,405, and406may be hidden, and replaced with a single input to confirm that a workflow should be automatically initiated. If a unique identifier is not present in the attached file, the “auto” tab may be disabled, or selecting the auto tab may notify the user that the file is not eligible for automatic workflow initiation.

If a user has filled in the various inputs402,403,404, and405, the user may select one of the options406: “reset,” to empty the inputs of all information if one or more inputs contains erroneous values; “initiate workflow,” to cause a workflow to be created according to the input values, but no further action taken, or “initiate and claim,” to cause both creation of the workflow and assignment of the workflow to the user to continue processing it in workflow management software.

When the “initiate workflow,” “initiate and claim,” or similar choices which may exist in other embodiments are selected, the plugin may cause workflow software to be launched, and may, via an API or other system for communicating between distinct applications, cause one or more textboxes, selection boxes, or other form elements or GUI elements to be prefilled with the selections from inputs402-404and with one or more data elements obtained from analysis of the file indicated by input405. As a result, the user of the workflow software is not able to make a human error in the selection of a file, selection of workflow options, or in the selection of a filename or folder for the documentation of the instructions.

APPENDIX A