Apply OOP techniques in answering difficult questions from customers
Some of my customers liked to ask questions beyond the scope of my product, especially when they found out that this is my own company. However, not all questions can be easily answered without exercising a bit of selective truths. Well, in object-oriented programming we called this “Data Abstraction”:
Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Below are some of the difficult questions and its corresponding abstractions:
***************************************************************
Question: How many people are there in your company ?
Answer: Currently there are five of us, plus some temp staffs.
Abstraction : In the “MyCompany” class, there is 1 director and 3 other passive shareholders. To simplify things, the class only exposed the attribute “people”, which is the total number of active and passive headcounts, to outsiders. Hmm…did I mention my pet ?
Question: How many customers from my sector are using your products ?
Answer: (Insert a respectable yet reasonable number here)
Abstraction: In the “MyCompany” class, there are 3 private attributes concerning number of customers: “total customers”, “potential customers” and “existing customers”. However, we only provide accessor method for the attribute “total customers”, which is the sum of “existing customers” and “potential customers” multiply by a random constant.
Question: How long has this product been in the market ?
Answer: Around 2 years.
Abstraction: Well, the first version launched 2 years ago is far inferior to the current latest version. But the truth is, it is really in the market for around 2 years.
****************************************************************
Well, it would be rather suicidal to reveal to customers that this is an OMO (One-Man-Operation) company. They would most probably not give you the chance, and instead opt for an inferior product from a bigger company. Or in some case, they would try to “eat” you by requesting a lot more features while reducing the price.
As for question two, nobody wants to be the pioneer to try out a new product, even though it had already proven working in some other sectors.
I guess sometimes in life we need to be selective in what to say and what not to say, even though we may not like it, as long as we are not hurting anyone in the process. Applying “data abstraction” techniques is just one way of doing that.
Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Below are some of the difficult questions and its corresponding abstractions:
***************************************************************
Question: How many people are there in your company ?
Answer: Currently there are five of us, plus some temp staffs.
Abstraction : In the “MyCompany” class, there is 1 director and 3 other passive shareholders. To simplify things, the class only exposed the attribute “people”, which is the total number of active and passive headcounts, to outsiders. Hmm…did I mention my pet ?
Question: How many customers from my sector are using your products ?
Answer: (Insert a respectable yet reasonable number here)
Abstraction: In the “MyCompany” class, there are 3 private attributes concerning number of customers: “total customers”, “potential customers” and “existing customers”. However, we only provide accessor method for the attribute “total customers”, which is the sum of “existing customers” and “potential customers” multiply by a random constant.
Question: How long has this product been in the market ?
Answer: Around 2 years.
Abstraction: Well, the first version launched 2 years ago is far inferior to the current latest version. But the truth is, it is really in the market for around 2 years.
****************************************************************
Well, it would be rather suicidal to reveal to customers that this is an OMO (One-Man-Operation) company. They would most probably not give you the chance, and instead opt for an inferior product from a bigger company. Or in some case, they would try to “eat” you by requesting a lot more features while reducing the price.
As for question two, nobody wants to be the pioneer to try out a new product, even though it had already proven working in some other sectors.
I guess sometimes in life we need to be selective in what to say and what not to say, even though we may not like it, as long as we are not hurting anyone in the process. Applying “data abstraction” techniques is just one way of doing that.
Labels: Customer Service, Entrepreneurship, My Adventure in Uncharted Waters
posted by The Uncharted Waters @ 5:05 PM
Comments: 3
