We live in a world where customer experiences with your company is spread far and fast. The way your customers will value your company’s products is not only based on your products itself. It is for a great deal based on the way that you support your customer in his process of buying, returning or servicing your products. The support processes however are not always thought through and are often not well supported by IT systems.
To give you an example: in my town, garbage is collected in underground containers. In order to get access to these containers you need a key card. Some time ago I couldn’t find my key-card and after turning my home upside down and inside out I still couldn’t find it. I decided to order a new one through the municipalities website and paid for it; I was happy with this service. A few hours later however, the key card I’d been looking for, showed up in an unexpected place. I decided to cancel the order for the new key card. I looked for the option on the municipalities website, but it wasn’t there. I called the municipalities office and got helped nicely but it seemed there also was no option for them to withdraw the delivery of the new key card through their systems. The civil servant decided to just continue delivering the key card and refund the order amount. I got helped nicely, but it left me puzzled with the question why there is no support for such an obvious scenario. Why wasn’t it possible to cancel the order?
To formulate the question in a broader perspective: How can process analysts and IT personnel forget to implement some of the quite obvious customer scenarios?
I believe the answer lies in the fact that employees setting up the support procedures lack a good model on what scenario’s to support. The quality of support is then in the hand of the employees drafting the procedures. Techniques like the voice of the customer are helpful but may overlook situations. What if there was a model that they one could use to make sure all possibilities are thought through? What if they had a structured way of drafting support procedures?
The Design and Engineering Methodology for Organizations methodology (DEMO) provides a model for this. The methodology is based on the theory of human cooperation and the research of consequences of it for organizations (research of Habemas, Austin, Searle, Bunge and Dietz) the DEMO methodology provides a pattern for a transaction as described in the example. It’s a scientifically based pattern but is easy to understand as it is common to all of us since we use it all the time.
Let me try to explain part of the model based on an the example I just used. Imagine the situation where there is no IT system to support the transaction between me and the civil servant. For simplicity I also take the payment out of the scenario. In this example I go to the municipality office to get a new key card:
- I request: “Can I please have a key card as I lost the one I got initially?”
- The civil servant promises: “If you live in our municipality I can give you a new key card”, he checks my passport and his registration and confirms that I live in the town.
- The civil servant gets a key card (execute)
- After coming back to the counter he states: “You can take this key card to open the underground container.
- I accept the transaction by picking up the key card and thanking the civil servant for his swift service
There are 5 elementary steps in this transaction
DEMO gives a thorough definition of these steps of a transaction. Any transaction we engage in, in real life will follow these steps. Since the real life processes are the basis for IT systems support, we can benefit from this pattern.
Beside these 5 basic steps there are some other scenario’s possible that again are well defined in DEMO:
- If I don’t live in the town, the civil servant can decline my request.
- While the civil servant walks to get the key card and I found the original one in my wallet, I can revoke my request.
- if I see that the key card is one for a different type of container I could reject the it when it is on the counter.
- If I get home and the key card doesn’t work as expected, I could also revoke the acceptance of the key card by going back to the counter and returning it.
- And some more…
The full DEMO transaction pattern defines 15 activities like “request, decline, accept, revoke accept” and describes how we end up from one state into the other if we are for instance to revoke a promised fact. If we consider all the steps in the transaction pattern, it will helps us to create the proper support for our service teams and for our IT support. It prevents us from overlooking a scenario.
To my opinion, DEMO provides models that are very useful for anyone working in the field of business process management and the (IT) support of human centric business processes. It provides a basis for designing business process and designing the support for it. One of the models I described here makes us consider all steps in a transaction so we can make sure that all options are well supported. Not implementing a step could cause an overload on your service center having your agents to solve issues that could have been prevented by thinking through the process using the DEMO transaction pattern.
