Creating the Policy Application

Figure 3.4 illustrates the new process for issuing a policy at Highlight Insurance.

Figure 3.4: Software for issuing a policy

Unlike a quote process, a policy issuance can take several days. The steps involved are as follows.

1. Receipt of policy request: Highlight Insurance receives policy requests from different sources. The company Web site is the primary source, and from there, both agents and customers can submit policy requests. Requests also come from agents who transmit files on behalf of customers. A stored quote is a prerequisite to a customer's requesting a policy.

2. Data storage: The following cases apply:

   • After providing credit-card details at the Web site, the customer's (or agent's) click invokes the ProcessPolicy service. That service then invokes a data-access service to get details on the quote being accepted, invokes other services described in this list, and returns control to the Web application, which reports that the purchase is in progress.

   • If an agent submits a file, the service ParseAcordPolicy reformats the input and invokes the ProcessPolicy service. With SOA, the file transmission is viewed as a service invocation and results in the same behavior from ProcessPolicy, which requires no change to accommodate the different interaction pattern.

   • The ProcessPolicy service provides an operation that lets a customer or agent query the status of a policy request. To support that operation, ProcessPolicy stores the current process status while moving toward issuing a new policy.

   In general terms, ProcessPolicy indicates whether to issue a policy, to reject the policy request, or to contact an underwriter for intervention and for possible user (or agency) contact. ProcessPolicy issues a rejection immediately, for example, if the customer did not request the policy in the timeframe specified (and in that case, the customer must submit a new quote request, usually by modifying and resubmitting a previously saved one). Communication with the applicant is by email or postal service.

3. Verifications: ProcessPolicy verifies details, and policy issuance usually becomes more likely at each step:

   • Services provided by the accounting and finance group handle credit checks.

   • If credit checks result in approval, ProcessPolicy invoke services provided by the DMV to verify license and vehicle status.

   Whenever possible, Highlight Insurance runs checks at the same time to speed a response to the customer.

   The service handles some situations (a failed credit check, for example) but defers to underwriters in others, as when the question arises, "Did a customer provide data mistakenly or to defraud the company?" For example:

   • A submitted vehicle identification number (VIN) refers to a car of a different make and model than specified by the customer.

   • A submitted VIN refers to a car owned by a driver other than one mentioned on the policy.

4. Decision: If policy issuance is appropriate, the QuoteManagement service calculates a quote based on a variety of risk factors. In this way, the same calculation occurs for both quote request and policy request.

   You may ask, "Why repeat the calculation?" Although Highlight Insurance retains a customer's trust by honoring a previous quote, the quote may no longer be appropriate. The verification process may have found new information, for example, or government regulators may have required a lower valuation since the quote request. Highlight's designers decided that a re-invocation of QuoteManagement in all cases was the best way to ensure that the price reflected the company's intent.

   Highlight Insurance has a two-step process for final approval. The CreditAndAccount service creates the policy, which then is evaluated by an underwriter.

   From the perspective of the ProcessPolicy service, the underwriter (a person) is a kind of service. The WS-BPEL4People specification proposes a formal mechanism to describe the interaction between automated processes and persons, as described at the following Web site: http://www.ibm.com/developerworks/webservices/library/specification/ws-bpel4people.

5. Communication: If the underwriter decides that the policy is valid, ProcessPolicy invokes the CreditAndAccount service to begin a policy billing cycle and issues an email and the legal paperwork by invoking the PrintShop service. If the policy is not valid, ProcessPolicy invokes the voidPolicy operation of CreditAndAccount and informs the customer (or agent) that a policy is not being issued.

6. Cancel purchase: Highlight Insurance lets the applicant cancel the purchase even after the company has fulfilled some or all steps in the multi-day process of issuing a policy. The application provides a compensation action, as explained in Chapter 2. In this case, the user's cancellation request causes a new invocation of CreditAndAccount, which voids the new policy, and invokes the PrintShop service to inform the customer about the changed status. If Highlight already sent the paperwork for a new policy, the company sends legal cancellation documents.