Implementing Services Using the Transaction Pattern How to retain the customer perspective when specifying requirements Customer journeys usually include several touchpoints at which the customer transacts with a business. Transactions occur when stakeholders exchange value, as in “I pay some money in exchange for your product”. There is usually a request from one stakeholder and a response from the other. The tool described in this article, Graham Wilson is a business architect at Robinson Ryan, a specialist data management consultancy based in Australia. Graham has 30 years of experience implementing business systems for government agencies in Australia and New Zealand. He is currently writing a book on transaction patterns to be published later in 2018.
the ‘transaction pattern’, breaks down this fundamental requestand-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 86 Touchpoint 10-1
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
