Meaning of Inquiries from Customers…
In Japan, we have an expression “A customer is a god.” Inquiries from customers might be literally “voice of gods.” At least, there are large differences between such customers and others who leave things they do not understand.
Many companies set up a support center to deal with complaints of customers. Such a support center may be a call center or an inbound e-mail correspondence team. This “activity to meet complaints” is, seen from another angle, a “Process that enables us to list pieces of information which are not well informed to customers”.
The reasons why customers are not well informed are various.
- The information is not sent. (Lack of information transmission)
- The information is sent, but its quality is low. (Quality of transmitted information)
- The information is sent, but it cannot be found. (Search-ability of transmitted information)
Anyhow, “listing of pieces of information that are not well transmitted to customers” can be a stepping stone to identify the causes.
Also Inquiries within the Company
In my considered opinion, there are important tips in inquiries within the companies, too. Probably, “things to be announced inside the company” should include “things to inform customers of.” If we can make a list of “the thing to be announced in the company,” it is very useful to secure the completeness of “things to be transmitted to customers.” That is to say, it is more likely that “lack of information” can be avoided.
If necessary, one can receive suggestions (T1), undergo evaluations (L1, Mb1), and record quality of responses (L2). Such application control is illustrated as follows.
Formulated Recording of Responses
To manage progress of inquiry correspondence is effective to “deal with complaints” as soon as possible. At the same time, to continuously logging the responses leads to future improvement of the information transmission.
Figure 3 (Reprinting)
Start with Resolving Lack of Information
Sharing formulated inquiries and responses might not look special, but it is very important.
In addition to the improvement of information transmission aiming at just reducing the number of inquiries, we may want to reduce the requests for advises of R&D by sharing knowledge etc., particularly in case of organizations requiring 5 or 10 responders in the support center.
As a general measure for improvement, we can add information to FAQ. But if possible, we want to gather measures for improvement besides just adding them to FAQ. I would illustrate a process below in which each Participant prepares a draft of a measure for improvement in advance in order to dare to have periodical meetings to discuss various measures for improvement.
Even if we add FAQ to resolve the lack of information transmission, we had better to examine “whether the quality of explanations of added information is satisfactory or not” or “whether added information is confusing because of its similarity to other information or not.” In some cases, we might need to change or remove existing information to be transmitted. There are few organizations that can thoroughly manage FAQ for customers. There is almost no organization that can manage FAQ for inside the company.
Needless to say, meeting minutes themselves are important data for subsequent improvement activities.
If No One Knows, Create Information
When we treat information that someone probably knows, we just need to find such a person. For instance, we can consult developers when we deal with specifications of a product. However, there is sometimes a case in which we are required to answer to inquiries regarding “unknown and undecided information.”
More specifically, we can expect various cases such as a specification policy of an unreleased product or information about the release date. However, any consultant in R&D section cannot answer at his/her own discretion. Needless to say, a person in a support center has no way to do that.
In the first place, a Process in which a draft is brushed up based on the consensus of members is difficult. However, it is obvious that a rough draft is necessary.
On the basis of the rough draft, we must discuss thoroughly. In some cases, we need another draft. Then, we should manage the generated new information with the consensus process.
Drafts by Two People Is Better Than Ones by One Person
“Two heads are better than one.”
In all countries, it is said that a better conclusion is led when multiple people gather. But the number of heads varies, say 2 or 3, depending on countries.
The same reasoning works out also regarding the creation of rough draft. When we define and transmit new information, we hope to express it in a considerate manner so that more people can easily understand. Here, we think about a Process in which a discussion regarding the final draft is carried out based on two rough drafts, which are created by different people in advance.
We should note that two draft creation tasks (Ma1, Mb1) are carried out in parallel after a theme is decided (L1). For example, this can be a Process in which we expect “arbitrary two people” in the team to make drafts about the development policy concerning a product specification.
Each split in a Diagram is called as follows.
- A split selecting one flow is called “XOR-Split.”
- A split selecting more than one flow is called “OR-Split.”
- A split selecting all flows is called “AND-Split.”
L1 is AND-Split and D1 is XOR-Split. Depending on BPM engines, you could face some limitations. For example, you might not be able to use OR-Split or And-Split in case a flow goes out of a loop.
Discussion on Organization Policy Triggered by an Inquiry
As an example, let’s assume an inquiry from an important client. In this case, triggered by an inquiry, we need to create a response document.
This sample Diagram shows a case in which each sectional adviser “brings back the inquiry to the section to examine and respond it in a document.
Establishment of Consensus
In order to establish consensus, discussions are indispensable. Based on the business contents, a Process Owner needs to consider well what Process is appropriate to reach an agreement in the group. Such a Process always has a loop.
Most of Tasks are supposed to be executed by “someone” in the group defined in Swimlanes. In addition, when someone has already executed a Task in a Swimlane, such as Ma2 Task in Figure 7, that “executor” will be appropriate to carry out the others in the Swimlane. That rule is called “Retain Familiar.”
In fact, in Draft Editorial Meeting in Figure 7, we could say that the “anyone” can “Take Meeting Minutes,” but it is more natural to think that there is a task that is to be executed by “everyone.” And, implementation of “Task by Everyone” varies depending on types of BPM software. [The End]