CHAPTER 3

Responding to Requests

People, patterns, and prehistory

People appreciate the value of a good pattern. With a desire to make something and a pattern in our hands, we are no longer starting with a blank sheet of paper. Instead, we have a tried and tested way to move forward. People have used patterns for centuries to achieve all kinds of purposes – sewing clothes, making metal tools, making furniture, building houses, getting married, developing software. Patterns are as old as humanity.

Consider for instance the people who inhabited Britain around 5000 years ago. They performed great earthworks that created new spaces in the landscape for socializing and ceremonies. These ‘social enclosures’ held special significance, not only for the resident community, but also for others outside the community who walked for many days to visit them. Because of this special meaning, other communities wanted to create their own social spaces and in doing so, they followed the pattern others had used. The earliest earthworks were comprised of two or three concentric circles made by digging circular ditches and piling the rubble beside them in a low bank. This simple pattern for creating a gathering place spread rapidly through the scattered population and was repeated many times in various parts of the island. A henge is a type of enclosure with a single circular bank and ditch, and two entrances opposite each other, as shown in Figure 3-1.

Later, a new pattern emerged in the same region for creating sacred burial places. Constructing a long barrow involved a more complex pattern requiring a multi-stage process – selecting a conspicuous site; finding, moving, and erecting stone slabs to construct a chamber of stone and a passage into it; then finally excavating from nearby a vast quantity of soil or chalk and piling it on top of the chamber.

The pile of rubble was narrow and elongated – hence, ‘long’ – with ditches on each side that supplied the covering. The long barrow pattern was learnt and repeated many times over, from the south of England to Orkney and west to Ireland, but it was especially popular on the chalk downlands of the south, where the pile of white chalk created an unmissable gleaming landmark.

Figure 3-2 Standing stones guard the entrance to West Kennet Long Barrow, Wiltshire, England6

A third pattern that became popular was erecting circles of tall narrow stones. Like the circular banks and ditches, stone circles created special enclosed spaces for ritual gatherings and other communal activities, including midsummer and midwinter celebrations – the New Year’s Eve of ancient times. Like the long barrow pattern, the stone circle pattern was deployed thousands of times far and wide throughout the British Isles.

Figure 3-3 Castlerigg Stone Circle, Cumbria, England7

The stone circle pattern and the circular bank and ditch henge pattern were sometimes combined, as shown in Figure 3-4, so that the structure could serve multiple purposes – e.g. as a social gathering place and an astronomical observatory. The henge-stone circle combination was employed on an immense scale at Avebury, shown in Figure 3-5.

Figure 3-5 Avebury henge and stone circle, Wiltshire, England8

There were often local variants of the pattern that emerged as a result of the materials that were available, the character and position of the sites people chose for their enclosures, and community preferences. Long barrows became circular passage tombs in some places. Passage tombs were built on a massive scale and included precise alignment to the solstice. Some stone circles included secondary circles made of different stones brought from further away. But in all cases, the established pattern is still recognizable – a stone circle or passage tomb in Orkney is remarkably like one located in Wiltshire or Cornwall.

Innovations also occurred now and again that changed the pattern significantly. Some of these innovations were one-off creative bursts, such as the famous and massive trilithons at Stonehenge, which were so resource-intensive and technically challenging that they were never attempted elsewhere. But those who followed the pattern closely could learn the techniques and borrow the necessary labor from other communities.

Like ancient Britons, modern businesses depend on established patterns for smooth internal operations and organization. In addition, businesses rely on other businesses to use similar patterns so they can conduct commerce with each other without needing to learn the ropes every time. Occasionally, a business invents a completely new way of operating and earning revenue – today we are very familiar with this through the many businesses which are leveraging digital technology to disrupt their industry and rapidly gain the lion’s share of the market: Uber, Google, Amazon, Apple are examples. In some cases, these innovators are defining new patterns that others will follow, while others are building complex and enormous ‘stonehenges’ that may never be replicated.

In this chapter, we look at a simple pattern that is easy to replicate and can be applied to any business that transacts with customers – we call it the Transaction Pattern. But first, let’s sit with Emily in one of her weekly meetings.

Emily is annoyed. The weekly operational status meetings in her insurance claims department are so frustrating. The team leaders struggle to compile their reports and discuss their workloads and issues. One person turned up late because it took her an hour to assemble a report of her team’s current work. Another team leader is complaining about going through this torture every week. During the meeting, it is almost impossible to work out whether a team has a lot to work on, or not. Why is this so hard?

Emily has noticed how agitated the department manager becomes when the three team leaders report on their workloads and seem to be talking in different languages. One person says, “We have 50 transactions in a finished state, and 23 in progress, 4 of which are blocked.” Another team lead reports that “We have 37 new registrations come in this week and we have requested clarification from a third party on 3 of them. The other 34 have been done. Three new claims were reported this morning that we have not started.” Emily wonders: Does ‘finished’ mean the same as ‘done’? Does ‘blocked’ mean the same thing as ‘requested clarification’ or something else? Of the 23 newly received transactions, how many have not commenced processing yet? Is a ‘registration’ the same as a ‘claim’?

Emily wonders why they don’t use the same words to describe the work. If they did that, then it would be easier to compile an aggregated report showing the department’s work in totality in one table or graph.

Are the processes for dealing with motor vehicle claims, house claims, and travel claims really so different? She knows that each process uses status codes to indicate where a transaction is up to in the process. The motor vehicle claim process has a status called ‘Received’ to indicate that information about an incident has been submitted by a claimant. A claim for a home and contents loss has a status called ‘Lodged’ to indicate that the application has been received but not yet processed. The process for lodgment of a travel claim uses a status called ‘New’ for the equivalent step.

This confusing situation is repeated with other status codes across the three processes, finishing the processes with ‘Finished’, ‘Registered’, and ‘Done’ depending on the type of insurance claim. In all, there are thirty different status codes across all three claim types.

Emily wonders whether the status codes could be made uniform across the three processes. This would reduce the number of status codes from 30 to 10, and Emily suspects those 10 could be simplified even further. For example, the statuses ‘Approved’ and ‘Rejected’ indicate the outcome as well as a stage in the process. To produce the weekly status report, the number of approved and rejected transactions need to be added together to give her the number of transactions that have been completed. Wouldn’t it be simpler to have a single processing status of ‘Decided’? The content of the decision (approval or rejection of the request) could be recorded in a separate field designed for that purpose, rather than embedded in the status code itself.

A smaller number of status codes, limited to standardized processing statuses, would certainly simplify the reporting and reduce the manager’s confusion. This would also mean that the status reports from each team could be aggregated easily by adding up the numbers of transactions at each status. The manager could see the total workload and how it is divided between the teams. Emily thinks that if this happens, the status discussion would be so much more straightforward. The information could be displayed in real time as transactions occur, using a simple dashboard.

Emily thinks there must be a way to standardize the status codes in this way across the processes for all types of insurance claims. After all, the processes are not dissimilar. Perhaps the problem has arisen because the systems that support each process were built at different times by different developers. It is possible the developers made their own decisions about many aspects of the system design without considering the context of all the department’s responsibilities and their need to be operationally efficient across all business lines.

Business processes and the transaction pattern

Emily’s insurance company processes a claim for vehicle damage differently than a claim for home contents theft, and differently again for travel claims. Emily cannot think why these claims have very different processes and why each business process is specific to a product.

Businesses often create distinct processes for each of their products. Often, this is the result of company mergers and acquisitions. But it is more likely that the processes have just evolved differently because separate departments manage the operations for each product. There is a significant cost to two (or more) different processes that do similar work. These unnecessary costs come from several direct costs, as well as lost opportunities such as: limiting staff mobility between departments and extra training costs, maintaining two computer systems, and creating data that is not easily compared between the product lines.

Businesses can save these unwanted costs by moving away from product-based processes towards a more generic process structure. A generic process can be applied to any of the company’s products with minimal customization. The Transaction Pattern detailed in this book is one such generic process structure.

Using the Transaction Pattern, Emily will be able to strip away the product-specific variations from the processes so that the fundamental tasks that are performed on all product types are revealed. A generalized process like this is adaptable to new products and other changes in the business operations.

Transactions comprise a request and a response

Every business service is an exchange between two stakeholders. There are two types of services:

This book, for the most part, addresses transactional services, rather than information services. This is because most challenges facing computer system designers and business process designers lie in the complexity inherent in many transactional services, compared to the relatively straightforward provision of information. Also, patterns for information services are well-established in the website and web content design spheres.

As we described in Chapter 2, a transaction results in a change to the records of a business, whereas an information service does not. Our use of the term ‘transaction’ is broad and may or may not involve a financial transaction. ‘Transaction’ is a convenient label for any kind of exchange between stakeholders, including money, goods, licenses, and claims. Transactions also include updates to stored information, such as when a customer changes their address.

Typically, one stakeholder requests something of the other stakeholder, who decides what to do about the request and responds accordingly. Sometimes a transaction involves a customer requesting something from a business – for example, “I want to buy this book.” Other times it is the business initiating a service with the customer – for example, “Here is our invoice; payment is due in 7 days.”

Our use of the word ‘stakeholder’ here is deliberate. ‘Stakeholder’ is a neutral term that signifies that the customer, the business, or a third party may be the one making the request, or conversely responding to the request. In other words, sometimes the requester is a customer, but in other transactions the requester is the business. Which is which depends on the nature of the transaction.

Many transactions begin with a request from a customer, such as a product order or an application for a permit. We refer to these types of transactions as ‘externally triggered’. Transactions that commence internally to the business include billing processes in which an invoice is generated and sent to a customer – essentially, an invoice is a request from a business who is owed money, with the expectation that the customer will respond with a payment. We call transactions that are commenced by the business itself ‘internally triggered’.

Both externally-triggered and internally-triggered transactions are important and commonly occur in most businesses. For clarity in this chapter we will focus at first on externally-triggered transactions. The pattern for business-initiated, internally-triggered transactions is slightly different and is discussed separately later in the chapter.

Thinking more generally about different externally-triggered transactions, we can see that all types of transactions involve two distinct parts – first, a request from a customer, followed by a response from the business. Table 3-1 shows some examples to demonstrate this pattern of request-and-response.

The feature common to all these examples is a clear break between the customer request and the business response. The requester has stated what they want. The second half of the transaction creates the business’s response to that request.

Transactions exchange value

The customer’s request is offering up something that is of value to them in anticipation of receiving something else of value from the business in return. There is always such an exchange of value between the stakeholders. The end of a transaction is marked by the delivery of something of value to the customer – that is, the value they were seeking by interacting with the business. For example, a permit to do some regulated activity, the settlement of owed money, a product they wanted to buy, or confirmation that their recent change of name is updated.

In Table 3-2, we have suggested the value exchanged between the parties in the example transactions.

Knowing the value that is exchanged is very useful, as it enables us to identify individual services and to distinguish them clearly from other services within an end-to-end customer journey that may stretch across time and involve several distinct services. The delivery of the requested value marks the completion of a transaction.

In a customer journey, this point is often a touchpoint between the business and customer, notifying them of the business’s decision in response to the customer’s request. Decisions are a vital element of a transaction.

See Chapter 4 for more information about customer journeys and touchpoints.

Transacting requires a decision

As well as passing between the request and the response stage, a transaction always involves a decision about whether the business can fulfil the customer’s request, or not. In other words, will the business participate in this exchange of value with the customer? For example, an online retailer might confirm that it holds stock of the desired goods before it commits to accepting the customer’s order. The bank makes a detailed assessment of an application for a loan and decides whether to offer a loan and on what terms. An insurance company will decide the monetary value of a customer’s loss, based on the business rules that the company applies to the policy that the customer purchased. (Incidentally, the purchase of the policy is a separate transaction that must have occurred previously.)

The decision made by the business allows the transaction to reach closure, albeit not always to the customer’s satisfaction. For example, a decision to not grant a driver’s license (because the new driver failed a test) nevertheless completes the “Apply for a driver’s license” transaction. We have added the decision that the business must make for each of the example transactions in Table 3-3.

The approval or decision action is often the clearest signal that a transaction is happening rather than an information service or a customer interaction. A customer journey may comprise many such decision actions. Identifying these decision points enables us to rapidly identify each distinct transaction within the end-to-end customer journey.

Transactions follow a consistent pattern of changing statuses

These examples show that a consistent pattern, comprising a request from one stakeholder followed by a response from another stakeholder, commonly occurs in business transactions. Now let’s look deeper into what lies within each of the request and response stages.

All types of transactions are processed via a similar sequence of work activities. Each activity causes the status of the transaction to change. The status of a transaction is usually expressed in a single unambiguous word, or an abbreviation such as a three-letter code; for example, Submitted or SUB. Because it cannot exist in two statuses at once, the transaction clicks through a sequence of statuses one at a time, in response to the work that is performed on them.

We generalize these activities and transaction statuses to create a generic pattern that is applicable to many diverse transaction types. The example that follows illustrates how the generic pattern can be discovered amongst the details of a specific transaction. In the narrative below, the transaction’s shifting statuses are shown in bold as we describe each phase of the transaction.

A typical example is an insurance claim, in which a policy holder notifies the insurer of a loss. You will notice that, in this illustration, the insurance claim transaction is described, at various points, as Initiated, Submitted, Accepted, Decided, and Completed. These are called transaction statuses. Every transaction moves through a defined sequence of statuses. The transaction’s status tells the business what needs to be done next with the transaction. Thus, in the broader context of business operations, information about the current status of all active transactions is critical to managing the company’s work.

During the Request half of the transaction, the customer initiates the transaction by identifying themselves to the insurer’s website and selecting the type of loss they have experienced. The website may apply a profile of the customer, depending on what the insurer knows about them – e.g. a high-risk customer may be asked more questions about the loss than a low-risk customer. At this point a transaction has been initiated and we say that the transaction’s status is now Initiated.

The customer then enters data in answer to a series of questions and attaches evidence in support of their claim (e.g. a death certificate for life insurance, photos of the damage in the case of property or vehicle insurance). The customer confirms these details and then submits the claim. The transaction has now reached a Submitted status.

Submitting the claim is, in effect, a request to the insurer to assess the claim and make a payment in recompense for the loss. Submission of the claim marks the end of what the customer needs to do, and it completes the Request half of the transaction.

Now it is the insurer’s turn to respond. Until the transaction has been submitted by the customer, the website has not done very much other than retrieving and presenting information to the customer. However, once it becomes Submitted, the claim is transmitted to the back-office systems to be assessed. The insurer’s back-office staff (or possibly an automated system) will validate the details and attachments provided by the claimant and match the claim to the relevant policy. If these validations pass, then the claim can now be accepted for assessment. The transaction’s status moves from Submitted to Accepted.

The claim is then passed to an assessor, who assesses the loss, decides whether the claimant’s policy covers the loss, and calculates its value. The status of the transaction now moves to Decided. The insurer will then notify the claimant of the assessor’s decision and may execute a payment to settle the claim. The insurer has nothing more to do, as they have completed the response half of the transaction. The transaction status now changes to the final status in the sequence, Completed. In the above example, an Initiated insurance claim is in the customer’s hands, until it becomes Submitted and the insurer receives it. A Submitted claim needs to become Accepted before the assessors can examine the loss and decide on the settlement amount. Once the claimant has been notified of the decision and the payment executed, the claim has been Completed. This sequence is shown in Table 3-4.

This example follows the same pattern no matter what type of insurance policy and type of loss are involved. In fact, the pattern is so common that most insurers employ a very similar pattern when they make attempts to standardize claims processing across their business.

A generic pattern of request and response

By detailing the process in the example above, we have identified that the transaction moves through a sequence of named statuses, as work is performed on it. By removing the specific details of the insurance claim transaction, we are left with a generic request-and-response pattern. The pattern comprises a progression of five transaction statuses interspersed between generic processing phases.

We have arrived at the basic request-and-response pattern that many transactions conform to. We call this generic pattern the Transaction Pattern. The Transaction Pattern is illustrated in Figure 3-6.

Now, returning to Emily and her issue with the weekly operational status meetings. If all the transactions across Emily’s department were to adopt the standardized statuses of the Transaction Pattern, the frustrations would disappear. Each team leader’s reporting would be easy to interpret, because all reports are based on a common language, so to speak – everyone knows what Accepted and Completed mean. Measuring the volumes of active transactions in each of the five statuses would be a simple counting exercise, performed in minutes. We build up the details of the Transaction Pattern, and the benefits of using this pattern, in later chapters.

Requests are resilient to changing response processes

The customer’s request is very stable relative to the processes and systems that create the business’s response. For example, a utility company will always receive certain requests from their customers, because people move to a new house, people cannot pay their bill, people want to know how much energy or water they have used, and so on. The information that the utility requires to process such requests remains remarkably constant over time. This means that the request needs to be resilient to any changes in back-office systems and processes.

For a century or so, people lodged their requests with the utility using the telephone or a paper form without much changing. Meanwhile, the utility’s processing and recordkeeping methods may have evolved significantly over the same period. The pace of change has picked up with computerization and the digitization of services, but businesses need to be mindful that the request component of their transactions should be resilient to the frequent upgrades and replacements that they make to the computer systems. A business should be able to change something in the response part of a transaction without needing to also change the request part.

Varying the transaction pattern

We have described so far in this chapter how a transaction comprises, at the highest level, a request from a stakeholder followed by a response from another stakeholder and looked into the details of the Transaction Pattern that applies to externally triggered transactions, in which a customer makes a request and the business responds. Now let’s turn our attention to other scenarios, for example when the business initiates a request to a customer and the customer responds, and when a transaction is triggered by the arrival of a scheduled date. The Transaction Pattern readily adapts to these scenarios and – like any good pattern – can and should be varied to suit the nature of each transactional service. Firstly, we will look at making minor variations to the pattern to suit internally triggered transactions. The following section discusses three distinct pattern styles reflecting differing levels of complexity. These three styles can be used as the basis to find the right variation for a particular transactional service.

As we saw earlier in this chapter, an example of an internally-triggered transaction is customer billing, in which an invoice is generated and sent to a customer. Essentially, an invoice is a request from a business to a customer who owes the business money; the customer has an obligation to respond to the invoice with a payment. Billing and reconciling the payments received is a function that all businesses depend on for their financial viability and there are well-established and standardized approaches to performing the function, usually known as ‘Accounts Receivable’.

Another group of internally-triggered transactions is scheduled transactions. These occur when an activity is scheduled to occur at a date in the future by being placed on a calendar of planned transactions. The scheduling of the future transaction is done at the end of an earlier transaction. When the scheduled date arrives, a new transaction is commenced by the business and a correspondence is sent to the customer informing them that there is an obligation that they must attend to.

The circumstances in which scheduling of future transactions might be necessary include the following:

• renewal of a permit or license
• review of an arrangement between the stakeholders, such as an individualized plan of in-home care
• activation of an extension clause in a service contract
• review of a customer’s borrowings from a financial institution.

An internally-triggered scheduled transaction is typically commenced by sending the other stakeholder a notification to inform them that the business has commenced the transaction. You will have received notices telling you that your driver’s license is due to expire, and you will need to renew it, by paying the fee and passing any required driving or knowledge tests. Similarly, people who receive financial or other support from government services are asked periodically to attend the office for a review of their support arrangement and their compliance with the obligations the arrangement places on them. These are internally-triggered transactions.

Sometimes, care is needed when discerning whether a transaction is internally or externally triggered. For example, an invitation from a government agency to apply for a round of grant funding may appear to be a transaction that is triggered internally by the agency. However, it is simpler to view the invitation to apply as an information service (called, say, Invitation to apply for grant funding), rather than the start of a transactional service. The customer is free to choose not to apply for a grant. So, if we regarded the invitation as the commencement of a transaction, the transaction would be left hanging forever if they did not apply. If they choose to apply, a transaction is initiated by the applicant – i.e. the transaction is externally triggered. There are two business services at work here, the invitation to apply (an information service) and the application itself (a transactional service).

The Transaction Pattern may need to be adjusted slightly for an internally-triggered transaction. One or two tasks may need to be moved from one phase to another, or some tasks removed altogether, however wholesale changes to the pattern should never be necessary. For example, in the case of a legal notice that should be approved by a senior solicitor before it is dispatched to the client, there may need to be a task added to the Submit phase to approve the notice. The task of identifying the customer could usually be omitted from an internally triggered transaction, as the identity of the customer is already known. In the case of a billing transaction, there is probably no need for a task in the Decide phase to approve the reconciliation of the amount received, since the relatively simple task of matching the amount of a payment with the amount due on the relevant invoice doesn’t need a decision to be made, and the transaction can quickly move into the Complete phase.

Three styles of transactional complexity

We have seen that transactions vary widely in their purpose, but all transactions involve a request and a response, passed between two stakeholders. The Transaction Pattern comprises a request from one stakeholder (“I want to open a bank account”) and a response from another (“We have opened your new bank account. Your account number is …”). The final thing to consider in this chapter is the varying complexity of processing required by differing transactions.

Emily knows that in her department the complexity of a transaction varies, from a simple information update that needs little or no processing to a complex sequence of tasks involving workflow and multiple interactions with the customer. Some transactions require very straightforward processing, while others require lengthy and complex business processes. Emily wonders if it is realistic to force-fit every transaction into a one-size-fits-all Transaction Pattern.

We saw in Chapter 2 how transactions update the business’s master data. Some updates to master data need to be more controlled than others. In the case of a government agency, a transaction to update a customer’s address may be straightforward and may not require any approval step. On the other hand, an update to the bank account of a welfare recipient may require verification and approval to mitigate the risk of fraud. Therefore the “update my address” transaction could be fully automated – or at least have minimal handling and certainly no approval step – whereas the “update my bank account” transaction would need to make its way or ‘flow’ through the pipelines of the work process to a verification officer (and possibly to a second approval officer).

The above examples suggests that there are three distinct types of transaction:

1. A direct style that can update the data records with no approval step.
2. A ‘workflowed’ style that involves a sequence of tasks that humans need to handle, possibly with the help of decision-making computer systems.
3. A case style that is more fluid.

Direct style – A direct update of data, not requiring Validate or Decide phases.

The Direct style is suitable for updates to any master data that do not require checking or approval, such as updating addresses or other contact information.

Workflowed style – Tasks ordered in the common request-and-response pattern.

In the Workflowed style, a sequence of work tasks is followed, as we have described extensively in this chapter. This style allows for the possibility – indeed the probability – that different people may undertake each task. That is, tasks may pass from the workflow of one team into the workflow of another team.

The workflowed business tasks are sequenced in a repeatable, structured pattern. The tasks performed by both stakeholders follow a natural sequence that is similar across many transactions. Each task is assigned to a business role or team, either internally or externally. This allows not only for the customer to perform tasks, but also for external third parties to perform certain tasks, such as when an external payment service or credit check service is used within a transaction.

Case style – Some transactions are more complex than a simple linear sequence. This third style of transaction is more complex and dynamic. Tasks are selected, at the time of designing the workflow, in a sequence that is specific to the transaction. The tasks are still workflowed around the necessary teams, but not necessarily in a linear sequence like the Workflowed style.

We call this more-complex transaction style the ‘Case style’, as it resembles the fluid nature of case management work. In case-like business processes, the process steps and tasks will vary between cases depending on their content and what happens while the case is active.

In complex transactions, the Case style allows the transaction designer to determine which tasks (selected from the master list of tasks) are required to process the transaction. The designer can then place the tasks in the necessary sequence. As in the Workflowed style, each task is assigned to a business role or team, either internal or external. During the operations of a Case style transaction, the tasks that the designer has selected are workflowed to the people and teams in the correct sequence.

An example of a Case style transaction is registration of a company, which requires a great deal of information to be exchanged with the registering authority. This can be a barrier to even starting the process for some applicants. To improve the customer experience, the registry might break the registration process into two stages. This might avoid the need for the applicant to provide all the required information upfront, as this would be unnecessary if the applicant were to fail to meet a qualifying criterion. The first stage would require only the qualifying information to be provided, while the second stage would seek more detailed information.

The service journey that stakeholders prefer may be as follows: initial qualifying check of basic information, followed by the submission and evaluation of further information, enabling a decision to be made. In this case, the designer would select a sequence of work phases such as the following:

1. Initiate
2. Submit A
3. Validate
4. Request for more information
5. Submit B
6. Evaluate
7. Decide
8. Complete

You will note that there are two Submit phases. These will be similar in form but will transmit different information. Both Submit phases involve the following: navigating to the correct place to enter information, responding to a set of questions, checking the responses, and submitting. The Validate phase will assess only the applicant’s qualification for registration (by applying a set of business rules), while the Evaluate phase will assess the information that is sent in the second Submit phase.

This example is intended only to show that the selection and sequencing of the phases are flexible in the Case style of transaction. Another transactional service may need an entirely different sequence of work. For instance, applying to be enrolled in a government program for ongoing in-home support services, or seeking assistance with exporting goods to a new market, may require significantly different sequences of work phases.

We need to be cautious before using the Case style, however. It may be tempting to use the Case style because it can be made to closely align to an existing business process. This is a mistake, because this approach would mean that little streamlining of the business process would be achieved. On closer examination, we may find that the business process can be streamlined so that it fits the Workflowed style. This is a much better outcome for the business, as it simplifies the implementation and operational management of the improved process. It is worthwhile taking the time to work out whether the existing business process can be modified so that it conforms to the Direct or Workflowed style.

The Transaction Pattern provides a framework that constrains the types of work that can be performed in each of the five phases. A validation task can only occur in the Validate phase, while an approval task must occur in the Decide phase. If two validation tasks are needed at different times in the work sequence, then the transaction needs to have two Validate phases. Mixing validation tasks in with other tasks that belong in a different phase will inevitably complicate the number of status codes that you need, and therefore lead to complex system implementations and, consequently, difficult operational management meetings. The work tasks within each phase may also be sequenced in a unique way that suits the needs of the transaction, yet this altered sequencing of tasks will not impact the transaction status that operates at the phase level rather than the task level.

The three transaction styles – Direct, Workflowed, and Case styles – give us a framework for taking transaction complexity into account and designing how a specific transaction should be processed in the most efficient manner.

Emily is thrilled to discover that her operational status meetings don’t need to be as fraught as they have been lately. There is a way out of this mess! Every process needs to adopt a uniform set of statuses and adjust their process design so that there is a clear and unalterable sequence to the changing status codes. Processes can be released from being specific to one product and designed in a much more generic way, so that it doesn’t matter which product is being handled. But how do we pay more attention to our customers’ perspective? Can we have generic business processes while giving customers a good experience? How do we move work around the team efficiently and in a way that enforces adherence to the new set of status codes?

In the next chapter we look at the customer’s perspective and how it is embedded in modern approaches to service design and customer experience.

Three key points from this chapter

• People use patterns for many purposes because they help us do things faster and more consistently.
• The Transaction Pattern consists of five phases in its default Workflowed style: Initiate, Submit, Validate, Decide, and Complete. The status of a transaction changes at the end of each phase. The phases contain work tasks that may be automated or workflowed to human teams for execution.
• The Transaction Pattern is flexible and can be varied to suit the needs of a specific transaction.