The tool described in this article, the ‘transaction pattern’, breaks down this fundamental request-and-response exchange into a generic pattern of phases and tasks that recur in most types of transactions. The intent of the service blueprint is retained by using this tool, which facilitates a structured approach to specifying business requirements for system development and process implementation.

So often, it seems, an implementation project loses something of the essence of the excellent service design work that has gone before it. The customer perspective is diminished, or perhaps the internal process journey is implemented in a clumsy manner that is little improvement on the old process. If either of these things occur, then the supposed benefits of an improved customer experience, or of digitising a service, will be lost. Typically, development teams create a host of user stories based on a somewhat loose understanding of ‘what the business wants’ and of the service designer’s work. A tool is needed that ensures the customer perspective is not lost when specifying business requirements for system development.

A transaction typically begins with a customer navigating to the right place (a webpage, service counter or contact centre, for example) to make a request, and identifying themselves to the business. Then the customer provides information, such as choosing the product they want to buy, or filling in a form. This is the ‘request’ part of a transaction and, once complete, it is submitted to the business via the chosen channel. The business will then validate the request and direct it to the correct processing system or team. The customer’s request is assessed and a decision is made. If human judgement is required, then the decision will be made by an authorised person, but increasingly, assessments and decisions are automated. The decision is then communicated to the customer and the response to their request is finalised.

It may be difficult to discern all these steps in a simple transaction such as an online purchase, but nevertheless they are there. The sequence of steps becomes more obvious in a transactional service such as ‘apply for home loan’ or ‘apply for permit’, in which a clear decision is necessary: approve or reject the application. The request-and-response ‘transaction pattern’ consists of five processing phases: ‘initiate’, ‘submit’, ‘validate’, ‘decide’, and ‘complete’.

At the completion of each phase, the state of the transaction changes. The state of the transaction enables the operations team to know what stage the process has reached, and what to do next. ‘Status’ is therefore an essential element of effective operational management.

Usually, businesses create a large number of status codes to indicate what has happened to a transaction. However, these status codes often mix processing states with other information such as the outcome of an activity, for example ‘approved’ or ‘rejected’. We have seen transactions with 30 different status codes; this is extremely difficult to manage operationally and adds considerable complexity to the computer system. The ‘transaction pattern’ contains only five states. When all types of transactions use a matching set of states like this, the implementation of workflows can be streamlined, which also allows the easy creation of reports and management dashboards that consolidate all active transactions into one view.

Tasks get the work done

Within each phase there are generic tasks that process the customer’s request. A task is a piece of work that can be assigned to, and completed by, one person or an automated system.

Some of these tasks may not apply to a specific transaction, simplifying the pattern even more. Some tasks may be substantial pieces of work that are conducted by humans, while others are quite simple, allowing them to be automated. You will notice that the request stage of a transaction contains tasks that are performed by the customer. The customer will not think of these as distinct tasks, and in fact the customer experience team should have designed a streamlined and seamless interface that masks them. Nonetheless, it is helpful if business analysts and developers adopt the task perspective to avoid overlooking some important considerations that must be specified as requirements. For example, it might be easy to overlook the classification rules of the customer’s request to determine which team needs to receive it.

The ‘transaction pattern’ provides a straightforward way to design the operational workflow of the transaction. During the requirements design process, work queues are created to direct work to the right team or person. Work queues allow a worker to see a list of tasks that are allocated to the team and ‘pick’ the next task to perform, preventing another worker from also claiming it. Workflow efficiency has a direct effect on how the customer experiences the service.

A structured workshop discovers requirements quickly

The ‘transaction pattern’ facilitates a methodical analysis of each task in turn, step-by-step through the transaction. For each task, standard questions need to be addressed, which are shown in the accompanying figure. The answers to these questions form the basis of the business requirements for implementation of the transaction. For example, for the ‘preparation’ task, the question “What new data does this task create?” will reveal the data fields that need to be included in the web form that the submitter completes.

The requirements should be discovered by stepping through each of the tasks in turn during a workshop with the key players, using the desired customer experience as the foundation. This approach narrows the focus of discussions and rapidly draws out the important requirements. Good facilitation will encourage participants to take a pragmatic and honest attitude, to identify the critical work activities and data needs for each generic task. Our experience is that a straightforward transaction can be workshopped in half a day, while a more complex service may consume a day. This rapid timeframe prevents the endless back and forth of user stories or other methods used to structure requirements.

Data is at the heart of transactions

Transactional services, by their very nature, create new data, for example a new customer or a new permit. How well that data is structured and validated has a direct bearing on whether the data is fit for purpose when it is fed downstream into management reports or used again in subsequent transactions. Poor data quality leads to poor service quality.

In this context, data is of two main types: master data and transaction data. In the case of an ‘apply for license’ service, master data holds information about the licenses that have been granted. Master data, which is critical to the business’s purpose, requires long-term recordkeeping; the issuing authority may need to refer to the master record of a license in the future.

On the other hand, transaction data stores operational details to help track the license application while it is being processed. Transaction data includes information such as the current state of the transaction, the tasks performed on it, and any data or attachments that workers and systems need to access during the transaction’s short life (such as the application form submitted by the customer and the assessment of the application). Therefore, transaction data loses its value quickly.

The ‘transaction pattern’ prevents transaction data, which is relatively short-lived, being mixed up with master data, which the business needs to keep for a much longer timeframe. This separation improves data quality and streamlines the implementation of services and the operational management of transaction processing.

Superior requirements retain the spirit of the service design

The ‘transaction pattern’ standardises the workflows and tasks using a simple structure and a common language that service designers, business analysts and solution architects can all agree on. It is an easy-to-understand framework that can be used to create business requirements specifications based on the service design products. By using the pattern, the intent and spirit of the service design work is retained because the pattern creates a superior requirements product thanks to streamlined processes, improved data quality and better communication. For example, in a recent client engagement, the requirements specification removed several low-value data fields from the existing web form, simplifying the customer interface and closely matching the intended customer journey.

This article is part of Touchpoint Vol. 10 No. 1 - From Design to Implementation. Touchpoint Journal is available to purchase in print and PDF format. Become an SDN member, or upgrade your community membership, to be able to read all articles online and download the full-issue PDF at no charge.