I recently looked into purchasing a new home laptop. While going through the online configuration process, picking everything from hard drive size to software versions, I came to a section about support. There were three levels, each with different costs and different benefits.
The first level was pretty basic. If you have issues, you call, and they give you “Silver” support. That pretty much means after going through a frustrating phone automated service, they’ll answer your call in the order in which it was received, listen to your problem, and then say “Hmmm…have you tried rebooting it?”
The next level offered was the “Gold” level, which gave you a different support number to call for a level above novice service, but was still automated. Oh, and you also gain the ability to mail in the laptop for repairs. (Sweet! I get to pack up my laptop and DATA and send it to someone I don't know for days! Gee, I hope they like my pictures and screen saver!)
The final and most expensive level of care was the “Platinum” level. Here you received a phone number that would immediately connect you to a human (what a novel idea!) who would offer you expert assistance, and if needed even onsite repairs.
After reading all this I just had to sit back in my chair, shake my head in disbelief at what I’d read, and say “Really? You can offer me a human voice and the very best support for a price, and yet you choose to give me poor, frustrating support for free?”
I closed out of the configuration at that point without purchasing the laptop. That’s just not good customer service. A good customer service department gives everyone “Platinum” support so that they don’t tarnish their company’s reputation with anything less than excellent service. I suppose ArcherPoint may have spoiled me to our doctrine of support. Regardless of whether we speak to you once a year, or once a day, you get the same high quality level of support.
After my laptop configuration adventure, I happened to think that this was a perfect example of something that NAV handles very well. So, to redeem the time I spent configuring a laptop that will never be, let’s use their three level customer servicea example as a development lesson.
Let’s say that our company has decided they want to offer different service plans to their customers. They’re going to allow customers to pick from Silver, Gold, or Platinum plans. The Silver plan will be the default, and will be free. But with the Gold or Platinum plans, we’ll provide additional services for an annual fee.
First, we need to connect this level of care to our customer card. Now we could create a second table with a code (Silver,Gold, or Platinum) and the description of the level of service. But then every time we needed to find the description, we’d have to search the secondary table to find it. We are dealing with a set number of options, and no service is not one. Therefore, we’d also have to build code into the customer card to prevent a user from adding a customer without a service level, and force “Silver” as the default. And we’d also have to ensure that no one entered “Aluminum” as a service level. But that’s not the NAV way!
In NAV, we have a data type called an “option” field. An option field allows you to limit the user’s entry to a set list of choices. It can also default to a specific choice. The values are seen in NAV with an “option string” field property, such as Silver, Gold, and Platinum. But if you view the field in SQL, you only see an integer, which is its SQL data type, starting with zero: 0 = Silver, 1 = Gold, 2 = Platinum
Here are some guidelines to help you decide when to use an option data type field instead of a code or text field:
An option field is defined not only by entering a data type of option, but also by entering an Option String property.
As cool as option fields are, you need to understand a few things about them before you start using them.
I hope you’ll find the option data type useful in your development designs, but please…not for customer service levels.
This Week’s Challenge:
Beginning Developers: Add a field to your customer card in your test database that represents some form of optional data. Set the field on some records, and then modify the option string and see what happens. Sometimes the best teacher is the problem we create.
Seasoned Developers: Maybe you’d like to share an option nightmare or a perfect use of an option field with your fellow blog readers? (Yes, I still have gold stars available!)
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics