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.