There’s a severe lack of balance in this whole conversation surrounding CarrierIQ. The fact that CarrierIQ logs keystrokes makes the whole issue so terrifyingly intrusive that it’s difficult to look at the broad picture objectively.
Working in telecom isn’t much different than working in application development. Consider this common scenario:
> A user’s application crashes. They immediately call your customer service and spew vitriol, claiming the application has crashed ten times in the last week and lost all their data. ZOMG!
> Because you’re a seasoned — albeit somewhat cynical — developer, you include a crash reporter component that sends you detailed application usage and crash information. You pull up the customer’s records and see the application has only crashed three times in the two years the customer has owned it. The log of their data file size shows the file size has only ever gone up, and the report of data file integrity that runs every time the app boots reports no issues reading the file. Ever.
Wow, this must be the worst customer ever, right? And what’s up with this developer spying on his users. What a sociopath, right? Oh, I see he has got SpyMeSat Mobile App to notify him when an imaging satellite could be taking his picture. Of course he would say he just needs new satellite images, but the real reason is evident.
Probably not. This is more typical than we’d like to admit, but what drives users to such hyperbole when reporting issues? Tech support practices teach users this behavior. In order to understand how, you must understand a few things.
First is that, to your customer, the technology is a “black box”. To quote Arthur C. Clark: “Any sufficiently advanced technology is indistinguishable from magic.” When a customer calls a support line, there is a good chance the CSR is going to have them go through some basic steps they’ve already tried. Unfortunately, you can’t just take the customer’s word for it, because customers are liars…
Woops. See what just happened there? That’s the second thing you need to understand: common tech support methodologies tell us to distrust what the user says.
Thus begins the cycle of distrust. A certain percentage of customers will lie to save time. Another set will lie because they *think* they know what’s causing the problem, but they lack the depth of subject matter knowledge to even understand why they’re wrong. The technology is magic to them, so “restart the application/device” might as well be “say hocus-pocus three times.”
This issue runs even deeper because many customers really *do not* want to call your support line. They really don’t. Who wants to feel distrusted? They learn from every support experience, and will often take the basic troubleshooting steps themselves. They’ll tell you this, but as we know, a certain percentage will lie, and you have no way of knowing who this percentage is, therefore we must treat all customers as liars.
You spin me right round
baby right round
like a record baby…
*Ah-hem…* Sorry.
In a tech support conversation, the customer very quickly feels distrusted, and as we know from some rather infamous psychological experiments [1], people who feel distrusted will act in a way worthy of said feeling. Because of this deep rooted, dysfunctional relationship with our customers, we develop solutions that circumvent the issue entirely and gather the data directly. Pay no mind to the man behind the curtain, and all that. You see, the customer relationship problems are the same in telecom as they are in application development; web or otherwise.
This begs several questions:
Why ask them if they recently rebooted the device when the technology can tell us so accurately?
Why ask a customer how many dropped calls they experienced if we can simply look at a log?
Why not have a look at where the user was when they reported poor call quality, so we can correlate it to our tower location database?
Why trust that a particular setting is configured correctly when we can inspect the condition of the device?
*Why rely on a user’s assertion that they typed the URL correctly when we can just look at their keystrokes.*
Whoa, hold on a minute.
Let me back up a moment and be clear about something. I am not advocating that the data collection performed by CarrierIQ is “OK”. It’s also not entirely clear whether carriers can actually see your keystrokes, but they are logged on some devices. I am playing devil’s advocate here. I hope the scenario I’ve presented is identifiable to you. The technical groups at the carriers want you to have a positive experience, and this drives them to collect data.
I know more than a few people who work in technical departments at AT&T. They don’t live in a mountain-side complex plotting schemes for world domination. They really don’t. They’re normal people like you and I, and they care that people think their service sucks. Like we’ve all experienced, management doesn’t always give them the resources they need to fix the root cause. As is typical in service-related enterprise, they focus on *fulfilling* failure demand [2], rather than restructure their organization to reduce it.
This (excessive failure demand) is what drives the market for tools like CarrierIQ. I would be very surprised if the genesis of CarrierIQ was the marketing department, but the conundrum we face is that data collected for troubleshooting is like a trifecta of meth-heroin-cocain to marketers. The same data you’d need to build a robust support mechanism where the user does zero troubleshooting could be used to lead thousands of marketers right off a cliff. It’s too powerful an attraction. No firewall can withstand the gravity of “the bottom line”.
So take a step back for a moment and re-evaluate the CarrierIQ situation. Should there be more transparency? Yes, definitely, but let’s not turn this in to Salem 1692. These tools are incredibly valuable for carriers from a tech support perspective. They can’t go away entirely, but we do need better transparency and regulation of how the data is used.
Comments welcome on the [Hacker News item](http://news.ycombinator.com/item?id=329997).
—
1 – I’m referring to the [Stanford Prison Experiment](http://www.prisonexp.org/) conducted by Philip G. Zimbardo in 1971.
2 – [Failure demand](http://leanandkanban.wordpress.com/2009/05/24/failure-demand/): A work product that does not meet the customers needs and generates additional work. It is opposed to value demand, which is the customer wanting something new.