Are you a Service or Support organization?

In my voice-less trolling of meetings this week I participated in a rather pointless debate over definitions in trying to discover, after all these years, what type of an organization are we. Are we a support organization that delivers technical support and primarily assists users with the use of our products? Are we a service organization that delivers Internet services with support being just a minor component on that.

You can probably guess from this blog what my attitude is. If I could have spoken I would have asked “Is there any way we can penalize the idiots that request support for the fully documented issues, or because they didn’t RTFM – can we deny them support on the ground that they are too incompetent to request support and still get away with charging them?” 

I guess I won’t be writing the mission statement this year.

Division between service and support is a pretty big one – assume that its mutually exclusive as well. A good support organization should follow through with the customer until their problem was resolved, even if it involved third parties. A good service organization would deliver a solid product that didn’t require support. A milkshake.  

So what about offering support as a service? I’m a little divided on that one, mostly becausue I have yet to meet an organization that can do it well and still scale. Yeah, small consulting outfits like lawyers and accountants and corner shirt store can do it very well, but they can’t scale. When they do scale, you end up on the phone with India. Even Kinko’s to an extent does this, if you take them a project that is too complex or needs to be done on the short schedule, they will not do it while you wait. Want 2,000 copies, bonded and perforated – sure, give us an hour. Want a banner? Whoa, whoa, give us a few days.

The other limitation in support as a service is the matter of boundaries. How do you clearly communicate where your support ends?

Today I worked an issue I like to call “Support as a disservice” – I helped one of our partners customers partners. Try to wrap your head around that one for a moment. Our partner had a client who was getting upset that they were not receiving any email from their remote billing partner. Any email. After three wasted tickets of “It’s not our fault, next” and days of “no email” from the customer I got on the horn with the IT guy at the remote office and tried to get to the bottom of it. They didn’t have a mail server – they used their ISPs mail server. They also got a bounce back saying that the message was not delivered due to the timeouts. So today, I was on the support call with my partners customers partner and their ISP guy who didn’t have access to their server mail logs. (another reason phone support blows, you always get the lowest dude on the totem pole); In the end, we concluded that the mail is flowing, except in some cases involving some funky configuration on the partners customers partners ISPs mail server.

Do you see the problem here? This issue involved six people in five different organizations, and yielded one very helpless and disappointed third party, which will no doubt reflect poorly on my product even though its not my fault to begin with. So even though we went that extra mile, as a support company, we would easilly earn the Suckiest Support of The Year award. However, as a service company we proved that the product works, that there are no issues and we went a little further to help an unrelated third party see that we stand behind our services.

My basic thesis is: It is easier to define limits for a service organization because your deliverable is a particular feature (ie, you get to send email) where a support organization can either have a happy customer with all problems solved or an unhappy one that is uncertain of why they are paying us. With the later, there is no happy middle because the limit of “how happy are you” is hard to measure and while your support can make lots of people happy, you can still lose customers because some will feel you have not done enough.