Customer Service, Roles and Responsibilities

This week the marketing group is getting a bit frustrated, because we’re having a difference of opinion about service levels, resource availability, access to databases and servers – all exacerbated by the new owners handing down edicts for reporting requirements that are absolutely taking priority over all other work, no matter what expectations may have been set in the past.

Observation #1: Is the term “Customer Service” applicable to IT?

Some of the pushback I get comes in the form of complaints / comments about poor “Customer Service” – an excellent concept for a business’ customer touch points, but in many ways misapplied internally for an organization.

Heresy, I know – but here’s my Very Simple Response to these comments …

I send invoices to customers.

<disclaimer>Ok, if your IT organization charges back to internal operating groups, you need to disregard this Observation. I feel your pain, I’m not a big fan of chargebacks, it focuses on the wrong things …</disclaimer>

Think about it. When I complain to a vendor, contractor, etc. about customer service, they usually go the extra mile in the short term, but eventually we will have the serious discussion about service levels, expectations. Bottom line – if I want better / faster service, higher throughput, more support calls answered on the first ring, etc. – I will have to pay for it.

When Miller writes about this, he’s correctly talking about working well with others, giving people respect, delivering that little something extra that is a terrific way to build excellent working relationships. The problem is when folks translate “priorities have changed and I cannot deal with your request for 5 days” to “I don’t care what you need, it’s not getting done”. The real issue is scarce resources and changing priorities; the correct response is to realize that IT (and HR, and Finance, and Legal, and any other internal “service” organization”) and the operating groups have a shared problem, and need to work together as partners to resolve the issue. Also, resolution options must include compromises like adjusting expectations, adjusting scope, and questioning the statement “we’ve always done it this way”.

Action Item #1 : Develop partnerships with other groups in the company, not vendor/customer relationships.

Observation #2: If IT can’t help, we’ll do it ourselves … but IT should support the results long term.

This is 2004, for goodness sake, and computers, databases, web architecture, etc. are not magic to the business people in the company … however … there are clearly limits that all need to appreciate. We found out just this week that a new web-enabled database intended for the DMZ was planned – the contractor was lined up, had submitted a proposal, budget approved, and just needed a SQL table created.

Access security? How big would the table grow to? What server was required? Gee, the spec mentions a number of tables. Did you guys want this stuff backed up?

And oh, by the way, let’s not overcomplicate because we’ve already promised delivery for an immovable deadline a few weeks out.

Not surprising, we’ve been through this before, we can have the conversations and get things lined up. But I think the most interesting part of the conversation dealt with life after the “project” was complete – I reminded them that IT could not support what we weren’t involved in implementing. The response?

Well, we’re keeping this simple and we aren’t expecting any bugs / issues long term.

Ok, I really try hard to not take over conversations, speak condescendingly, refer to past history, etc. – it’s a personal conversation style, and I’m trying to work the partnership angle (see above). However, at times like this, I’ll trot out this Very Simple Response…

You know why I don’t sell water softeners? Because I don’t know how.

Folks need to realize there is a certain depth of complexity to things. It’s all Microsoft’s fault <facetious grin /> – selling an application as powerful, extensible, flexible etc. as Excel for $200 bucks makes folks think that cheap = easy (ok, how about inexpensive = robust).

Some related writings on this topic –

• Mark Hall article in ComputerWorld this week talks about the impact of modern IT architecture, and how the business analysis and requirements definitions are much more “critical path” than the technical / implementation details. Correct to some extent, but we can’t oversimplify the art of translating business requirements to what’s technically possible, sustainable, and supportable. (Please note – lots of budget landmines in those last two words).
• Mike McBride points out some pretty critical caveats re: the sophistication of the “IT Generalist” or “Business Analyst” role that exists in small/medium businesses – like mine! Folks already stretched thin and not having much depth in large (ie. bigger than a departmental) technology projects can oversimplify technical requirements and underestimate long-term support costs.

Action Item #2 : Don’t oversimplify implementation and support details & costs – but realize some folks have to experience the pain before they understand.