The Importance of Customer Service

Today we have run the gamut of customer service experiences. For the first time in quite a while, We were flying on Air Canada. There was a time when we flew the airline enough to be among their elite frequent flyers, but not so much in the last few years. This is mainly because we found that they offered subpar customer service compared to their competitors and their frequent flyer rewards program is terrible. (FWIW, we fly primarily American Airlines these days but have also found that Jet Blue offers good service--they just don't serve many of the locations we need.)

Lest you think this is all about flight experiences, we encourage you to read on because we'll strive to make it relevant to our lives as IBM i application developers.

Today, we're using up a few of those last few frequent flyer miles we earned years ago. We had pretty low expectations of customer service. But boy have we been proved wrong. Air Canada had a change of equipment on our flight. As a result, we arrived at the boarding gate to find our seat assignments had been changed without warning. Not only that, we had paid extra for seats with enough legroom to be able to actually open our laptops and write this blog post (among other things). Surprise! Our new seat assignments were in the "normal" no-extra-leg/laptop-room seats. Considering we had paid a premium for the "extra room" seats, this seemed a pretty bad example of customer service, right?

When we complained (as nicely as we could manage at 7 a.m.--we don't do mornings!) about this to the gate agent, she initially told us that we'd be refunded the difference in price. Perhaps it was the look of disappointment on our faces at the thought of spending five-plus hours with our knees up under or chins, but for whatever reason she changed her mind and was able to come up with some seats where we could work. Unfortunately, they were not together. So she worked a little more and went the extra mile to find a way to rearrange some other passengers so that we could all get the type of seats we expected and paid for. Plus, we were able to sit together. Nice work!

Then on the plane, we found that the extensive in-flight entertainment offerings were virtually unusable because neither of our seats had properly functioning headphone jacks. We notified the flight attendant who initially apologized and suggested we try their "special" Air Canada headphones, which were worse than our own. We thought this was the end of that part of the story, although we were happy to see that the flight attendant noted the seat numbers to report the issue so maintenance could try to rectify the problem for future flyers.

It was still disappointing though because this was a long flight and while we had some work to do, we had hoped to kill some time by taking in a movie or TV show or two as well.

But things again changed for the better when a little later, the lead flight attendant came by to bring us vouchers as a small compensation for our inconvenience with the entertainment system. She also offered us a glass of wine. It was only 10 a.m. at this point, but we were sure it was 5 p.m. somewhere, so we said "Yes, thanks!"

The result? We're very pleasantly surprised with the customer service we received at Air Canada--both in the airport and in the air. We hope it's not a fluke and maybe we're seeing a new, more customer-oriented Air Canada that is very different from most of our experiences in the years before. We also saw other similar examples on the same flight. For example, flight attendants moved passengers and their bags into empty seats closer to the front because they had very tight connections due to our flight being 30 minutes late.

While we witnessed several examples of problems with Air Canada today, we also saw excellent examples of staff who took the time to see things from the customer's perspective and find a way to make it right. That's the essence of great customer service and we, and the other passengers affected, are clearly much more likely to fly with Air Canada again than if they had been brushed off in the way we have experienced in the past.

So how is this relevant to an RPG programmer's life? We think all of us are in a position to provide excellent service to our customers--who in our case are the users of our applications. Seeing things from their perspective is a good starting point. Being prepared to apologize when things go wrong and to do your best to make things right surely applies to any job, even programming.

Let's face it, we don't always deliver perfect applications the first time and on time, do we? Maybe we can strive to see if we can go beyond just fixing the problems that arise (while muttering darkly about "darned users"). We can strive to write our code in such a way that it's easier to test (thus causing fewer problems) and easier/faster to maintain and enhance. Using modern language features and modular coding techniques come to mind as ways we might do some of those things.

Excellent customer service should not be limited to retail and other service environments. It should be part of every aspect of everything we do in our working environments.

Dealing With Nulls

Our most recent IBM i EXTRA article covers a bit about dealing with nulls when embedding SQL into RPG. But it is by no means a complete study of all the options.

That fact was quickly pointed out to us by reader Rusty Gadberry from Arkansas Data Services, who offered his much simpler solution. So we thought we'd introduce that solution here and start a discussion on when this might be an appropriate way to deal with nulls

Here's the suggested alternative to our logic:

   Exec SQL   

    Select CustID, CustName, ifnull (CustSales,dec(.00,7,2))

     Into :CustID, :CustName, :CustSales

     From Customer

     Where CustID = :InputCust;

Using the IfNull function, this shop avoids the possibility of indeterminate data coming into the program. We've used this approach sometimes, as well as a similar alternative approach using the Coalesce function shown below. In both cases, if the CustSales column value is null, it will be replaced with a value of zero in the result set returned to the RPG program. 

    Exec SQL

       Select CustID, CustName, Coalesce (CustSales,dec(.00,7,2))

         Into :CustID, :CustName, :CustSales

         From Customer

         Where CustID = :InputCust;

Approaches such as these are certainly simpler (and we like simple!) for those cases where the only logic we would have performed once we discovered a null is to replace the associated column value with a "generic" default.

However, neither of these approaches caters to cases where the "nullness" of a value is significant compared to zero (or some other "default" value). If there weren't such cases, then why were the columns made null-capable in the first place? Perhaps by default/mistake? Admittedly, in the very simplified example in the article, such a distinction is a bit of stretch.

It seems to us that it would often be significant in the case of outer joins to know about the presence of nulls, regardless of whether a column were otherwise null-capable or not. And, of course, date columns rarely have an easy or obvious default value to substitute. So we stand by the need to have a way to interrogate the nullness of a column in many circumstances.

Perhaps this is a good time to encourage you to think about null capability in your databases. Traditionally, it has been rare to have null-capable columns, but since there is a definite difference between the concept of "no value" and a zero, blank or other special value, perhaps we should consider more carefully which columns should be null-capable and which should not (i.e., a blank or zero value in this particular column is not significantly different to null).

Many shops these days are "modernizing" their databases, so this makes it a good time to consider making such changes if/when they make sense. Of course, in doing so, we must also potentially add to the logic of all our RPG (and other language) programs that access that data. We would certainly have to add logic to use %Null when using RPG's "native" I/O. Perhaps for such databases we could even mask this additional complexity by using an OA handler? For those programs using SQL to access the data, the techniques shown here or illustrated in the EXTRA article will need to be utilized.

Of course, you may have your own approaches, which we would love to see you share via the comments!

Going Dark--Cold Turkey

As you can probably imagine, given our travel schedule and the nature of our work, our laptops and cellphones are an ever-present part of our lives. Being self-employed also means that a "day off" in absolute terms is a rare bird indeed. So when we set off on a short cruise last Friday, while we intended to avoid work and enjoy ourselves, we had just assumed that we'd probably spend at least the usual hour or so each day doing mail, etc. That was before we found out that the internet connection on the cruise ship was 79 cents per minute! The "bargain packages" weren't much better. Not only that but it was a satellite system and there were more disclaimers re performance expectations than you could shake a stick at, so it was hard to think of it as any kind of option.

No problem. Jon's new phone plan gives us unlimited 3G data and has worked very well as a hot spot. But of course like all cell phones it requires a signal--and for the vast majority of the voyage we were too far out at sea to get one.

Ok, so we were going to be forced to go dark and with no chance to even mentally prepare ourselves. Could we survive? And, perhaps even scarier, might we perhaps even enjoy it?

We did--and we did. In fact the last thing on earth we really wanted to do when we got into the hotel was check email, but old habits die hard. Perhaps if it had been a week-long cruise we could have resisted the temptation, but someone had to write the blog this week!

If, like us, you find yourselves forever checking email, Facebook, etc., then try going dark for a day. No cellphone, no computer, no nothing. It won't kill you and you never know, you might grow to like it!

TCO vs. TCA

In rereading some of the comments on our recent blog posts, we came upon one from Paul Fenstermacher on our April 1 blog, "Advertising IBM i." Paul's comment was, "... the people that sign the checks are not concerned with TCO, rather they want to know TCA, how much do I have to pay now."

That comment rang horribly true with us and certainly explains some aspects of the current rush to the cloud. Not that there's anything wrong with the basic concept of Cloud computing, but it should surely be part of an overall IT strategy, not the totality of it. However, to a company from the ever-growing group that simply manages to the next quarter, valuing TCA over TCO is the "natural" way to go. You can almost hear them shouting, "Never mind the quality; feel the width.” To such companies, moving everything to the cloud must appear as a very attractive proposition.

So we wondered if this was an area of current business practices that had been reported on or studied. Surprisingly, we found very little that didn't simply qualify as advertising for cloud services. But what we did find was interesting. Check out this piece from back in 2010. It's written from a mainframe perspective but makes a number of points that those of you facing this kind of mentality may be able to use to your advantage. Besides, it is always nice to know you are not alone!

Of course, from a purely IBM i perspective there is actually documented evidence that IBM i leads in both categories. If you find this hard to believe, check out this You and i blog post from Steve Will in late 2012.

On a completely different note, while wandering around in search of TCO/TCA material, we also came upon a great series of articles on "How Not To …" by Jim Schesvold right here on the IBM Systems Magazine website. We're not quite sure how we missed them when they were first published, but since we're sure some of you probably missed them too, we thought we'd pass along the link for the fourth in the series—not because it is better than the others, but because it includes links to the first three. They make for an interesting read, so do yourself a favor and pop over to Jim's piece on sweatshop mentality.

That's all for this week. Now back to work...