Customer Service? Optional?

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:

• Is the data pre-definable?  Do you know all the possible answers a user can give to this field?
• Are there more options than just No/Yes or False/True?  (Having only these two possibilities would make it a Boolean data type, which is similar to an option field in that you will see a nothing or a checkmark, but SQL stores a 0 or 1.)
• Do users need to be able to modify the choices that are given to users for this field?  If so, you don’t want an option because only a developer can change the choices of an option 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.

1. The first option is the ‘0’ option, and is the default. You can leave this blank if the field does not require an entry. To do so your option string would simply contain a comma as the first value (“ ,Silver, Gold, Platinum”). Using this option string, Silver becomes option 1, and must be selected.
2. Never (say it with me – “NEVER!”) change the sequence of the option string.  The numeric value does not change when you move them, say, into alphabetical order.  So if you change the option string from “Silver, Gold, Platinum” to “Gold, Platinum, Silver”, your customers on Silver customer service just got upgraded to Gold, your Platinum customers were downgraded to Silver, and your Gold customers upgraded to Platinum.  (Think for a minute about having to fix that!) The ‘0’ option value did not change in the field, only what it “means” when it’s viewed.  The string is only how NAV displays the value in the table – it does not affect the value itself. However, if you filter now on “Gold” as the Customer Service Type, you’re going to get those customers that were Silver prior to your option string change. 
3. When creating an option field, create your option string with room to grow.  For example, knowing that later on I may want to add other levels of service, I may want to create the option string as “ ,,,Silver,,,Gold,,,Platinum”.  The commas in the option string are still counted as an option value, making Silver = 3, Gold = 6, and Platinum = 9.  If later I decide to offer a Bronze level, I can modify the option string as “ ,,Bronze,Silver,,,Gold,,,Platinum”. The commas allow you to grow within the option string defined, but you can also add options to the end of the string without worry.  For example, I could later have “ ,,Bronze,Silver,,,Gold,,,Platinum,Fort Knox” without having the option numbers reassigned to the wrong option string name.  The empty comma placeholders don’t show in a drop-down of the field.  NAV knows these are not used, but “set aside” for later use.
4. When adding an option field to a form, resist the urge to fill in the option string property on the form.  If you don’t populate it, the field’s option string will be used.  Otherwise, you’ll create quite a mess for yourself later on when someone changes the option string on the table, and the form has its own option string that no one remembers to change.  The field on the table is dominant.  Let’s say your  form has “ ,,Bronze,Silver,,,Gold,,,Platinum” as the field’s option string, and that matches the table’s option string for the field.  That’s all well and good…until…someone changes the table option string  to “ ,Aluminum,Bronze,Silver,,,Gold,,,Platinum”, and your users cannot set the field to Aluminum because they don’t see the option listed.  However, oddly enough, they start seeing values of ‘1’ on records and don’t understand why (assuming there is another way the field gets populated than the form they have available).  If you set the property on the forms, you create an eternal job for yourself in maintaining the values as the field values change.
5. If you decide to carry your Customer Service Level field into the Sales Header, be sure – be very sure – you assign the same option string to the Sales Header field.  Otherwise, when the information is pulled into the Sales Header table “Customer Service Level” you will receive a different value.  For example, if the Customer option string is “ ,,Bronze,Silver,,,Gold,,,Platinum” and the Sales Header option string is “ ,Bronze,,Silver,,,Gold,,,Copper”, you will see a ‘2’ where you should see Bronze (which is now option integer value 1), and Platinum suddenly shows a Copper.  Keep in mind an option field is an integer value.  It does not follow your misrepresentation of the option string. 
6. When using the option field in code, you can use the string integer values, as in coding: “Customer Service Level” := 1 to set the field to Silver.  But that’s just not nice!  You lose the self-documentation of the field’s value.  A nicer way to treat the developers who will later modify your code is: “Customer Service Level” := “Customer Service Level”::Silver.

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!)