Personalization: a piece of cake?

07 March 2016

Say you’re an IT-professional working for a company that sells services, among which a punch-ticket for psychological advice by phone. You’re charged with realizing a first step in personalizing the consumer journey.

What does the road ahead look like for you? Register for our AE Foyer on The Challenge of Personalization if the following story sounds familiar to you.

Day 1

On a sunny Monday morning, a marketing manager drops by your desk with a seemingly innocent question:

“Hey, we’d love to show a personal banner on our website. Something really simple, visible to everyone who has called in for psychological advice, less than 3 times over the past 6 months. They get a message saying ‘Hi : Get in touch, you’ve got X calls left’. Well, except if they have a habit of not paying their bills. Can you check what’s needed and do what’s necessary to get this live by next month? This would +mean the world to me… it’s critical for me to stay on good terms with the big boss.”

Somewhat naive, you say you’ll have a look. How hard can it be, right?

Unfortunately, you might be in for one hell of a wake-up call. See, you’ve stumbled into a number of pitfalls with your eyes wide open. As a self-respecting IT-professional, you’ve probably even thought of a few yourself, like : a short-term production deadline, a question purely formulated in terms of a concrete solution, no preceding analysis, no project (yet)… just a ‘small’ business-as-usual request.

And well, you’re courageous and a good sport, you know the application landscape pretty well and you think you can score by making this happen.

After all, checking how often someone’s called and what for, that sort of data is no doubt stored in the organization’s call center application. And building a small service on top of that to fetch this information is a piece of cake. Who knows, maybe that API already exists? Let’s check our wiki if there’s any documentation about the API of our call center app. Damn… not a thing.

Ok, time to get in touch with the team that manages that app, which has to happen anyway. It seems to be completely outsourced. Let’s call… Great! You’ve got someone on the phone who can schedule a call with a ‘technical expert’ in two days.

Night 1

You dream about cool near-real-time-analytics-based self-learning personalization algorithms that go way beyond what you’re asked to do with that stupid banner.

Day 2

In preparation of your call with the API expert, you’re looking at the call center operators to send you a few concrete screenshots on slide that show which fields you need to obtain.

Alas, that proves to be more difficult than you assumed: the Dutch-speaking operators appear to have indicated the type of service by writing a line that says “*** type = psycho ***” in the “comment1” field. (Since January anyway, because before then some of them just wrote “wacko”). The French-speaking team has another modus operandi: in the (otherwise not used) “phase” field, they put the value “13”, if it pertains to psychological advice. Most of the time anyway.

To be completely sure, you request access to the application and the underlying database and you spend the rest of the day researching the data quality. Hmmm… perhaps it would’ve been better to call in a true analyst and data architect. Will the people in the call center even be open to changing their habits? Maybe a meeting with the operators’ team leads is in order. How much time is that going to take? Now you think “I’ll start with parsing those fields in my service, and I’ll refactor everything later if there’s a more unified way of working at the source.” Fingers crossed.

A typical obstacle of ‘ad hoc’ digitalization is that people are clever and creative. They’re smarter than the standard limitations of the software they (have to) use. If this software doesn’t fully support the whole process, a workaround often is quickly found. That doesn’t have to be a problem, unless you need to industrialize these creative workarounds because of an unexpected exposure to a new (digital) channel.

Day 3

Time to call the supplier’s API expert. Major bummer: “comment1” is not available in the API because it’s part of a customized screen that was developed for your organization only. A tailor-made API extension is proposed and an offer sheet is coming your way by the end of this week. The next release is in two months. Can it be done sooner? Sure, but it comes with a higher price tag as they’ll have to work the fast-tracking into their offer sheet.

Instead of getting depressed, you decide to move on and apply an old trick: you already define the provided interface for the service you had in mind, hiding away the language differences, and temporarily ‘mock’ the results from the Dutch data set. For the French ones, luckily, you can already test the link to the master system tomorrow.

Day 4

Operations wasn’t too keen on giving you access to that API, but a visit from your marketing manager does the trick: as long as it’s not in production and it’s for a quick experiment only, it’s all good.

Let’s give it a whirl. GetPhaseForRecurringCallsByCallerID ... wait ... ‘callerID’? Oh no! That must be the internal ID of the call center system. Damn, you’ll have to find a way to map that on the … uhm … surferID when someone’s logged in to the website. Ok, check, that’s something for next week. You’ve got access to the application now so you go about collecting a list of about 300 callerIDs to move forward with tomorrow.

Day 5

Four hours into the day, you’ve created a premature, quick and dirty web service. For the time being, it still uses the ‘callerID’, just to see if it works. A quick test shows that… YES, it does! Although it seems to be a little on the slow side.

Then you quickly write a script to launch your service for all 300 callerIDs in your list. You’re going for a coffee and when you return to your desk you notice there’s still no result. Weird… a timeout. Let’s give it another go.

Getting back to the coffee machine for an extra shot of caffeine, you spot a few call center operators having gathered over there. They were in training and all of a sudden their application froze and now they’re restarting the whole thing. Dark clouds are hovering above your head when you see you’ve got a missed call from operations asking whether you know anything about this sudden heavy load…

Clearly, this is not your best day. You put your experiment to a halt and conclude that, at least for reading existing data, a direct connection to such an operationally important internal system maybe isn’t the best idea after all.

As a matter of fact, “directly” connecting from your digital channels to operationally important internal master systems, just for reading data, is almost never a good idea. Most of the time, these systems are simply not designed to deal with an unpredictable number of users.

As the cherry on top, the offer sheet for adding “comment1” to the API of the call center software, drops into your inbox. And oh boy, is it expensive! You continue to think about a solution to the performance issues… and you feel those dark clouds getting thicker and thicker.

That night…

You’re all sweaty from a horrible nightmare: a court case of angry customers, who weren’t happy that their teenage kids got to see the banner too. Didn’t the guys from marketing say that this trick with that cookie was OK? Thank god it was only a dream. But will people like this banner anyway? What’s value is in it for them? Did they actually test the idea? And would it be okay, privacy-wise?

Now that you’re awake anyway, you realize you’ve totally forgotten to hold into account the bad payers, as well as the remaining calls on the punch tickets. Does the counter have to be correct in real time? And where can you find the data?

Day 8 (thank god for weekends!)

You go back to your marketing manager and you say this whole thing is a bit more complicated than you thought. You advise him to handle this as a real project (or program…) and to go to the AE Foyer on personalization where they’ll talk about these kinds of challenges and how to tackle them.

Want to know more about personalization? Join us on March 10, 2016 at our AE Foyer: The Challenge of Personalization.

Joris Van denstorme

Written by Joris Van denstorme

Post a Comment

Lists by Topic

see all

Posts by Topic

see all