• A Nerd With a View (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    Okay. That procedure is not optimal, but... where is the WTF?

    Apparently, it's "WTF? Nothing to see here?"

    Honestly, this sounds pretty typical. A 2-3 month period after rollout to get things stable is not bad at all, and outsourcing phone support is very common.

    As a developer, I don't want my customer's customers calling me. This setup sounds ideal from my perspective.

  • somebody (unregistered)
    a bit of investigation by one of SJ’s coworkers revealed how to get into the application's client database from the server, so they could actually check whether someone had an account, what their login information was supposed to be, and even reset passwords themselves (which until then was an unheard of amount of transparency for them).

    They got into the customer's database and nobody got fired. That's the WTF.

  • Chris (unregistered)

    "..For SJ, and others, one question remained: "Why can't the customers call the developer directly?"..."

    Because they don't have people skills! They are not good at dealing with people! Can't you people understand that!

  • (cs)

    Where's the WTF? This is just normal process. No WTFs here. Nothing even close to one. Very disappointing.

  • Kasper (unregistered) in reply to campkev
    campkev:
    If I was SJ's supervisor and overhead that conversation, I would have had a talk with him about how to speak to the customer and creating unrealistic expectations.
    Roughly the opposite happened to me once. I received a call from an unsatisfied user.

    Me receiving a call from an unsatisfied user would have made a lot of sense, if it had been a user of the system I was responsible for. However the system I was responsible for was only used in-house. This user was from outside the company, and the application he was complaining about was not supported by me, rather it was supported by a different division of the company on another continent.

    But since I did know about the application in question I tried to get him to explain what the problem was. If I was able to reproduce it and I could see the problem with my own eyes, I would be able to file an appropriate bug report.

    He could explain what steps he took. I tried the same steps on my computer, and got the result I would have expected. So I asked him what result he got and what result he was expecting. He couldn't answer either of those questions and complained that we were making things so complicated.

    At this point I had to remind him, that he was not talking with the right person, and I asked where he had gotten my number from so I could get it corrected. He told me he got it from our homepage, but the number listed there wasn't mine. The only way he could have gotten to me was by dialling my local extension. So this guy must simply have dialled a random local extension expecting whoever answered the phone would help him.

    When I finally got off the phone with him, the manager two levels up, who had overhead the conversation, said I was way too patient.

  • bar (unregistered) in reply to foo
    foo:
    Remy Porter:
    I think it's safe to say that the dialogue features some artistic license.
    Well, are we supposed to comment on what's written or read the editor's mind?
    perhaps we're not supposed to comment at all. No, that couldn't be it!
  • (cs) in reply to Kasper
    Kasper:
    campkev:
    If I was SJ's supervisor and overhead that conversation, I would have had a talk with him about how to speak to the customer and creating unrealistic expectations.
    Roughly the opposite happened to me once. I received a call from an unsatisfied user.

    Me receiving a call from an unsatisfied user would have made a lot of sense, if it had been a user of the system I was responsible for. However the system I was responsible for was only used in-house. This user was from outside the company, and the application he was complaining about was not supported by me, rather it was supported by a different division of the company on another continent.

    But since I did know about the application in question I tried to get him to explain what the problem was. If I was able to reproduce it and I could see the problem with my own eyes, I would be able to file an appropriate bug report.

    He could explain what steps he took. I tried the same steps on my computer, and got the result I would have expected. So I asked him what result he got and what result he was expecting. He couldn't answer either of those questions and complained that we were making things so complicated.

    At this point I had to remind him, that he was not talking with the right person, and I asked where he had gotten my number from so I could get it corrected. He told me he got it from our homepage, but the number listed there wasn't mine. The only way he could have gotten to me was by dialling my local extension. So this guy must simply have dialled a random local extension expecting whoever answered the phone would help him.

    When I finally got off the phone with him, the manager two levels up, who had overhead the conversation, said I was way too patient.

    "Hey! You got real good people skills! You're wasted in that dead-end programming job! As from next week you've been transferred to our call center! You're just the guy we want to take all the awkward calls from users who don't know squat and shout at you all the time! Clear your desk and you'll be on the next plane out to Poona!"

  • Matt (unregistered)

    So this is why everything customer support tells me is a lie. I would rather the no idea answer than being fobbed off with "a couple of days".

  • SJ (unregistered) in reply to Larry
    It's turtles all the way down! Recursion FTW!

    Wow, this actually got run... must've been a slow day. The writing isn't my best, and as has been pointed out, there is no real punchline, but I think this comment provides it. :-)

    As far as I was concerned at the time, TRWTF was that these customers called us hoping for their problems to be solved and we couldn't. We were in the business of solving problems for our customers; this sort of onion support contract was very atypical, and extremely half-assed. We had no idea what we were doing, next to no communication with Multitrode, and there was literally nothing that I could do about any of it except half-ass the best I could on my own and hope that someone I never met, talked to, or heard from took care of these poor schmucks. It made me rather bitter.

    As for the various professional conduct comments, yes, the transcript is closer to what went through my head than what went past my lips. But still, is it more professional to try to make up some sort of answer which is going to be a complete lie no matter what, or to say "I have no idea what's going on, I can't really help you"? I generally veered towards the former, but they're both rather bad choices.

  • (cs) in reply to Larry
    Larry:
    ... but skimming some of the dollars.

    Any financial whiz will tell you that's all that matters, right? Money making money, everything else is not real...

    Larry:
    It's turtles all the way down!

    Very apt: Not only the reference, but also the related attribute of slowness...

  • Nakke (unregistered)

    Client: "So... when can I expect to hear back from you?" SJ: (mumbled) "No idea."

    This reply is the real WTF of this story. If you can't handle the simplest rules of customer service, go work somewhere else.

  • minime (unregistered)
    For SJ, and others, one question remained: "Why can't the customers call the developer directly?"
    Well, SJ, simply because the developers get paid ten times as much as you and their time is just too valuable to bother them with stupid tasks as to deal with customers and the forth and back of getting the actually needed information...
  • Mary Davey (unregistered) in reply to Larry

    I remember the spaghetti model, then the lasagna model. After that came object orientation and encapsulation - the ravioli model. People still wonder why only the Mob can make sense of it.

  • vfxGer (unregistered)

    This seem doesn't seem like a wtf but a more business as usual, or maybe I have become very jaded.

  • Founder (unregistered)

    As a developer, I want to know when my software is not working. I would rather be directly in contact with the customer than try to interpret whats wrong off a support ticket.

    I don't want to be bothered every time someone can't log in, but if there's a real problem, I will contact the customer and work with them to resolve it.

  • Kasper (unregistered) in reply to Matt Westwood
    Matt Westwood:
    You got real good people skills!
    Nobody has ever accused me of that before.
  • Kasper (unregistered) in reply to Matt
    Matt:
    So this is why everything customer support tells me is a lie.
    If that was true, it would be much easier to communicate with customer support. In reality I think it is more like 50/50.
  • duis (unregistered)

    That's how we do things in Spain.

    End customer (usually the government or another big company) pays >500,000€ to one of the big companies, they take half the money and hire a smaller company, and the process is repeated until we reach the half-dozen inexperienced programmers who get paid 1200€ (OMG that's almost two times minimum wage!) to do whatever they have to do.

    I might be exaggerating, but just a little. Our "software industry" should explode and burn ASAP.

  • anon (unregistered) in reply to m
    m:
    Did anyone else notice that SJ's name changed to CJ?
    I assume a pseudonym, like many outsourced support companies. SJ, or "Steve Johnson", is probably actually Chakrapani Jaabir.
  • Tom (unregistered) in reply to Larry

    Larry that is one of the best explanations of the evolution of programs I have ever heard.

  • Tom (unregistered) in reply to Larry

    Larry that is one of the best explanations of the evolution of programs I have ever heard.

  • Ryan (unregistered)

    Well that was a bit anti-climatic wasn't it. Sounds like a pretty typical enterprisey/consultanty support/dev relationship to me.

  • (cs) in reply to (i|=J7}Y&.`Gb)
    (i|=J7}Y&.`Gb):
    So what do you call a network of daemons that interact with each other over multiple machines. Where each daemon is 5 lines of code and 1000 lines of boiler plate and you can tell what each daemon is doing but don't know who's telling him to do what?
    An Erlang system, except that it's easy to tell where the messages come from, and the boilerplate is all in the OTP (runtime library) and the virtual machine.
  • coyo (unregistered) in reply to Recursive Reclusive
    Recursive Reclusive:
    "lasagna apps" - I like that. Good metaphor.

    Give me the spaghetti over the lasagna, honestly.

  • (cs) in reply to SJ
    SJ:
    It's turtles all the way down! Recursion FTW!

    Wow, this actually got run... must've been a slow day. The writing isn't my best, and as has been pointed out, there is no real punchline, but I think this comment provides it. :-)

    As far as I was concerned at the time, TRWTF was that these customers called us hoping for their problems to be solved and we couldn't. We were in the business of solving problems for our customers; this sort of onion support contract was very atypical, and extremely half-assed. We had no idea what we were doing, next to no communication with Multitrode, and there was literally nothing that I could do about any of it except half-ass the best I could on my own and hope that someone I never met, talked to, or heard from took care of these poor schmucks. It made me rather bitter.

    As for the various professional conduct comments, yes, the transcript is closer to what went through my head than what went past my lips. But still, is it more professional to try to make up some sort of answer which is going to be a complete lie no matter what, or to say "I have no idea what's going on, I can't really help you"? I generally veered towards the former, but they're both rather bad choices.

    No, you simply tell the truth while making it sounds as good as possible. "I'm sorry, sir, but I can't provide a resolution estimate." If pressed for more, "How quickly it gets resolved will depend on the prioritization assigned to it by the development department. I have noted the urgency of the issue in the case notes." etc

    Giving a bogus time estimate is just screwing the guy who has to answer the call from the pissed off customer two days later.

  • Enduriel (unregistered) in reply to Larry

    Your post is so full of win, you simply win at the internet. Congratz to you.

  • katastrofa (unregistered) in reply to Larry
    Larry:
    Now we have onion corporations. No one really does anything. They just contract with someone else to do it. And if you peel away that shell (tearfully) you find another contact handing off responsibility but skimming some of the dollars.

    That's how you make the big bucks - by being the middleman.

  • (cs) in reply to vfxGer
    vfxGer:
    This seem doesn't seem like a wtf but a more business as usual, or maybe I have become very jaded

    No, you're not jaded, there is no WTF here. I was a bit shocked when I got to the end and there had been no punchline or WTF.

    This is a dull story about a fairly routine support contract with one slightly difficult aspect.

  • (cs)

    Customers should not talk to developers, the support desk is there for a reason: to handle the customers and to report bugs.

    Developers are there to fix bugs.

    Being asked for an estimated time for a bug fix though is always a WTF. It's fixed when it's fixed. I remember being called by someone on support continually being asked for "estimated time for fix" a long time ago. My answer at one point was that if he let me get on with it it would be fixed a lot quicker.

    What is good from the customer point of view is being able to remain updated as to the status of the bug, i.e.

    1. Been reported.
    2. Developers are investigating.
    3. Developer has reproduced the bug and is working on a fix.
    4. Fix has been made, tests are being carried out
    5. Fix implemented.

    An online ticket system will enable users to be able to track the bug without having to continually call. In addition it may be a "known" bug, i.e. already reported.

    Sometimes there is a known workaround solution.

    Most online support systems now take you all over several FAQs before you can raise a ticket or call anyone. Often annoying when the "contact us" page has no contact details but it does act as a filter for some of the more basic questions that get asked time and again.

    It's also useful for an online site to have "known bugs" so you can check if yours is listed before calling up.

    Bug-tracking / customer care software is not a trivial thing. A good system is a big development project on its own. Fortunately there are lot more good ones available nowadays than perhaps there used to be at the time of this incident.

  • Mark the Botcher (unregistered) in reply to Remy Porter
    Remy Porter:
    I think it's safe to say that the dialogue features some artistic license.
    Ryan:
    Well that was a bit anti-climatic wasn't it. Sounds like a pretty typical enterprisey/consultanty support/dev relationship to me.
    TheSHEEEP:
    Okay. That procedure is not optimal, but... where is the WTF?
    I think it's safe to say... Mark bowytzed it again.
  • Randy Snicker (unregistered) in reply to Larry
    Larry:
    Now we have onion corporations. No one really does anything. They just contract with someone else to do it. And if you peel away that shell (tearfully) you find another contact handing off responsibility but skimming some of the dollars.

    Onion corporations beat spaghetti support every time.

  • Martin (unregistered) in reply to Larry

    When times get tough in the onion corporation, you fire the handful of guys at the bottom who are the only ones doing any real work. All the others are important managers: you can't fire any of them!

Leave a comment on “Circuitous Support”

Log In or post as a guest

Replying to comment #:

« Return to Article