I was eating breakfast this morning when I noticed a receipt from Best Buy. I read the following at the bottom:

    Your Customer Service PIN is:
         nnnn nnn nnnn 022019

Where is n is apparently random numbers from [0,9]. The last section was clearly the month and year of purchase February 2019. This is a very poor customer facing ID. I will get into why shortly. As a side note, I’ve had to make customer facing IDs before for a product I worked on last year. (Sadly I cannot give much detail until the patent for the entire product goes through. It does make heavy use of IDs that customer may choose to write down.)

Here are what I consider to be key things a good Customer ID must have:

  • Easy for the customer to read and use
    • [ ] Short
    • [ ] Simple Characters
    • [ ] Possibly separated into smaller sub-sections of the entire ID
    • [ ] Easy determine character (zero vs the letter ‘O’)
    • [ ] Is it easy to read by someone with a reading disability?
    • [ ] Is it easy to read after being written down by someone with bad handwriting?
  • Easy for the system/help agents to read and use
    • [ ] Is it easy for an agent to understand the customer when read aloud the ID?
      • Usually, it’s just numbers. Maybe could be better though.
    • [ ] Is it easy for the help agent to enter into the system? (see customer section)
    • [ ] Is it easy to interpret by a help agent?
      • Is there information encoded inside the ID that only a machine can easily read?
    • Does interpreting the ID need to happen if systems (database,etc) go down?

While the list may be incomplete, it serves illustrates the point I wish to make. Let’s see what boxes this ID checks…

  • Easy for the customer to read and use
    • [ ] Short
      • 17 characters! Wow, that is not even remotely short. I seriously doubt they need all of that!
    • [x] Simple Characters
      • Only characters [0,9] very simple
    • [x] Possibly separated into smaller sub-sections of the entire ID
      • This number is very, very long so this is important
    • [x] Easy determine character (zero vs the letter ‘O’)
      • Yes, numbers are easy to read.
    • [ ] Is it easy to read by someone with difficulty reading?
      • No! It is very, very long!
    • [ ] Is it easy to read after being written down by someone with bad handwriting?
      • No! Depending on the person some numbers look the same, unfortunately.
  • Easy for the system/help agents to read and use
    • [x] Is it easy for an agent to understand the customer when read aloud the ID?
      • Usually, it’s just numbers. Maybe could be better though.
    • [x] Is it easy for the help agent to enter into the system? (see customer section)
      • Debatable, but since it is split into multiple parts, it’s probably ok.
    • [ ] Is it easy to interpret by a help agent?
      • Only the date of purchase can be understood but that isn’t useful since the date of purchase is already on the receipt. The agent likely has to look up the order anyway.
    • Does interpreting the ID need to happen if systems (database,etc) go down?
      • The agent is going to need to lookup the purchase

The Problem

This customer facing ID is very poor. It is meant to be read by a human but is very long so it is not very good for that. Imagine an elderly person, would they find it easy to read? Simply due to it’s length, they might not. Since this ID from Best Buy is a customer help ID, the person is likely already having a problem. What if they cannot read their ID out loud over the phone to the customer help agent? That just makes their experience even worse!

This problem exists in many, many places. How often are you giving out a very long transaction ID or customer help ID to read out load? You might say:

Ah but my service is not over the phone! My ticket ID, customer ID, etc. shows up in an email and the customer just copies it! Easy peasy! - Some Developer

It may seem rude to say but since when have customers ever done what you expected? Perhaps most of your user base will just copy and paste the ID but there will always be a portion of your audience that doesn’t. That portion will enter the ID several characters at a time looking back and forth between email and the help form. What a great way to make errors! Those users just so happen to be less tech literate in general so (depending on your product) they’re more likely to be requesting help! While it varies based on the audience, in general, this is a poor choice in my opinion. Yes, if the users of your service are all technically minded, this doesn’t matter much but that isn’t most services.

The Solution? … Maybe

Fortunately, Microsoft already came up with a solution. Have you ever noticed that some characters don’t show up in Microsoft Product Keys? That is no coincidence. Microsoft likely did an internal study and found that there are some characters that frequently are hard to read based on font, handwriting, the user’s vision, etc.

The following letters never turn up in a product key (well… except for ‘N’, they recently started using that one for a special purpose):

len(['A', 'E', 'I', 'L', 'N', 'O', 'P', 'S', 'U', 'Z', '0', '1', '5']) == 13

The following letters appear across all product keys:

len(['B','C','D','F','G','H','J','K','M','Q','R','T','V','W','X','Y','2','3','4','6','7','8','9']) == 23

Personally, I disagree with Microsoft a bit. ‘G’ and ‘6’ can look very similar if someone has bad handwritting. Sooo…

len(['B','C','D','F','H','J','K','M','Q','R','T','V','W','X','Y','2','3','4','7','8','9']) == 21

The idea is simple, instead of giving the user a number with [0,9] or a alphanumeric ID with {[0,9],[a,z]} instead give them an idea that only includes the above characters. The ID is more readable, easy to read after it is written. As a bonus, there are 21 characters so going from numeric to Microsoft’s characters allows for more compact IDs with fewer characters.

How? What?

Say you have an ID that directly corresponds to a row in a database.

12340789

You perform a base conversion from the above ID to the unique tweaked product key alphabet and you might get something like

FBRVX

That’s quite a bit shorter! Also, it can be written down and read easily! How much shorter will the new ID/code be? Well…

import math

before = 8 # length IDs were before
base = 10
baseAfter = 21

# the number of possible IDs of 'before' length
possibleValues = base**before

# after == 6.05
# depending on the ID, the actual base converted ID will be either 6 or 7
# since 6.05 is almost 6, most converted IDs will be 6 characters long
after = math.log( possibleValues, baseAfter)

# after == 7
# all converted IDs will use 7 or less chars
after = math.ceil(after)

Evaluation

Let’s evaluate the improved Best Buy customer help ID.

Before

    Your Customer Service PIN is:
         nnnn nnn nnnn 022019

A base conversion has been done and I have removed the month and year indicator since those are completely uneeded. Our code is now only 9 characters where it used to be 17. We did all of this with losing any information. After

    Your Customer Service PIN is:
            aaa aaa aaa
  • Easy for the customer to read and use
    • [x] Short
      • Maybe this could be better though??
    • [x] Simple Characters
      • Still common letters
    • [x] Possibly separated into smaller sub-sections of the entire ID
    • [x] Easy determine character (zero vs the letter ‘O’)
    • [x] Is it easy to read by someone with a reading disability?
    • [x] Is it easy to read after being written down by someone with bad handwriting?
  • Easy for the system/help agents to read and use
    • [ ] Is it easy for an agent to understand the customer when read aloud the ID?
      • No! It is actually worse than before. There are more characters to listen for now.
    • [x] Is it easy for the help agent to enter into the system? (see customer section)
    • [ ] Is it difficult to interpret by a help agent?
      • No, software needs to recover the original ID

This new code is better but it can be improved further. It can be even shorter. It also can be made to be easier shared by word of mouth.

The Actual Solution

People communicate through words. Our brains are hardwired for it. Computers, on the other hand, like numbers. When we communicate, we don’t spell out every word we use. We just use the whole word. Why are we forcing are users to use numbered like systems? It is inefficient.

Can you get the door? ‘C’.. ‘a’.. ‘n’.. ‘ ‘.. ‘Y’.. ……….

Let’s take advantage of the language people speak and stop ignoring it. What if we could take an ID and transform it into words… somehow.

12340789

Turns into

apple rug button

If you had to communicate this over the phone, the second is much quicker. The first has 8 syllables. The second has 4 syllables. The second is also much easier to check, understand, remember, and communicate. The user already has built-in error correction when it comes to reading words. If the word is written poorly, it is much more likely that the user will still be able to read it. Imagine how much it would suck if the ID on the receipt was partially rubbed out. With words, you would have a chance to still be able to read it.

Do achieve this in practice, you can use yet another base conversion! Instead of using a single character as a digit of the ID, each word is the digit. If you have enough words, the phrase ID is quite short. For example, if you have 1000 words available to choose from, you will need 3 words as the previous example showed. Or if you have an ID that is 11 number digits long, you will now need 4 words to represent the ID.

Here’s a list of 932 nouns.

The breakdown of the list is:

awk '{print length}' words.txt | sort | uniq -c

Word Length, Number of words
     10     18
     11     5
     4      74
     5      288
     6      246
     7      178
     8      83
     9      40

Final Evaluation

Before

    Your Customer Service PIN is:
         nnnn nnn nnnn 022019

After

    Your Customer Service PIN is:
      apple test mountain road
  • Easy for the customer to read and use
    • [x] Short
    • [x] Simple Characters
    • [x] Possibly separated into smaller sub-sections of the entire ID
    • [x] Easy determine character (zero vs the letter ‘O’)
    • [x] Is it easy to read by someone with a reading disability?
      • Choose short, simple words to help someone with dyslexia
    • [x] Is it easy to read after being written down by someone with bad handwriting?
  • Easy for the system/help agents to read and use
    • [x] Is it easy for an agent to understand the customer when read aloud the ID?
      • Usually, it’s just numbers. Maybe could be better though.
    • [x] Is it easy for the help agent to enter into the system? (see customer section)
    • [ ] Is it easy to interpret by a help agent?
      • No, software needs to recover the original ID

Warnings

If you are not careful about the words chosen…

  • there could be words that sound the same. pole vs poll
    • Solution no homophones
  • there could be phrases made that say inappropriate things
    • Solution only nouns

Even nouns together could can make sexual references, for example. So a thorough look at the word list is needed.

Conclusion

Customer facing IDs are just too long, too hard to read, and waste valuable time for both parties involved and they don’t have to be that way. See if there is way you make IDs shorter by including less redundant information and encoding them differently. Your customers will be happier. It will shorten the time talking with customers. Readability problems will reduce. It will reduce customer frustration.