If you make a payment over the telephone, the guy on the other end will usually give you a “confirmation number” that’s something like this.

1H779301-0104725367489-C7283S

I often joke that such a “number” is precise enough to define any particle in the known universe, but I’m exaggerating a little.

It seems absurd that the numbers are so long, but we all know how this works. Different positions in the code mean different things. E.g., the 2 digits before the first dash indicate the 2-digit year, and the 4 digits after the dash are the month and day.

This is supposed to be more “convenient” for somebody. They can look at the code and tell you which effort it was, or which phone operator, or whatever.

But who is it convenient for? It’s certainly not convenient for the customer.

This will become an increasingly important issue for publishers as we try to link the online and the print world.

For example, we may print customer numbers on mailing labels and ask the subscriber to enter that customer number somewhere online — to synch up the print and digital subscriptions.

If the customer has to enter 1H779301-0104725367489-C7283S he’s not going to be happy. Especially if it’s case sensitive.

So when your operations people argue for reserving positions X, Y and Z to mean A, B and C, just say no. Make your customer numbers (or equivalent) as short as you can.

Unfortunately, some of us are stuck with legacy systems and these awful, long, complex numbers are built into our data. You may or may not be able to fix that, but going forward, don’t make the problem any worse. Focus on short, simple codes that customers can use.

And while I’m on that topic, if you mix letters and numbers in your codes, you should probably set up the system so you never use zeroes or o’s, l’s or ones, etc. That is, don’t use characters that can be easily confused.