Early this past week I sent out an email to all company employees letting them know that I had finally implemented the Loyalty Points system. Now each employee would accrue 10% on every purchase which they could either spend along the way in small increments with each transaction, or they could save it up and get something for free later on.
My implementation of the new Loyalty Points program, which I named “ECRS Bucks” (I know, it’s lame), had several interesting (and helpful) side effects.
First of all, it provided an opportunity to host an impromptu training session with a new support technician who was not yet familiar with CATAPULT’s Loyalty Points module. The idea was to show him what transactions looked like before turning on the module, and then to walk him through setting up Loyalty Points in a live environment.
The process went very smoothly and took only a few minutes, and I could tell when we finished setting it up that he really “got it.” However, when we stepped next door to the break room, we discovered a problem on the transaction side that needed prompt resolution. The support tech purchased a beverage and the transaction’s “thank you” screen told him he’d just earned ‘x’ loyalty points on his purchase, which is the correct designed behavior.
However, when he accessed his account, those points were not displaying. We were able to have one of our developers fix the problem almost immediately. We assumed it was a bug, but the developer explained that whoever configured Loyalty Points (that would be yours truly) had not entered the proper IP address for the loyalty server. The developer simply changed the IP address, which fixed the problem.
This alerted us to the fact that we simply need to automate the entry of the loyalty IP address because “we know” (as they say in software development) what the server address is and can pre-populate that data for the user to avoid human error and the resulting GIGO.
The uptick in sales that resulted from the announcement of the new loyalty program also exposed another issue, which was that I hadn’t put up new price labels on the shelves since I’d processed the mos recent shipment of products. I had pulled off all the old stickers because many were mangled or misplaced, and I wanted to rotate the location of stock with the influx of new items.
My co-workers made it abundantly clear that they needed shelf labels. To assuage them until the shelf labels were ready, I put our price checker in the break room on the counter beside the dry goods rack. This would give employees a way to quickly and easily check the price of items before making their purchases. But I soon found out that this stop gap was insufficient, because most folks said they wanted to see all the prices at a glance, and that checking the price of every item they were curious about would take too long.
So in retrospect I see that putting the price checker in the break room was more self-centered than user-centered. That is, I saw it as an opportunity to snap on one more piece of our technology stack to be included in the overall experiment, which would help reveal both its value and limitations in a live environment. But the “spin” I put on it as a solution for the missing labels fell on deaf ears.
Yes, it’s nice to have it as part of the study, but it doesn’t solve the user side of the problem. I had baited my co-workers with a solution I thought would communicate my empathy with them, only to discover that what I’d really done was substitute empathy for them with a self-serving gesture. Time to get the mobile hip printer out and make some shelf labels.