• Spudley (unregistered) in reply to Kuli
    Kuli:
    My kkeybbboardd iiis brrrokkken. Pleeeaassse fixx the commment formm.

    Ohgreat.Nowthedarnspacebarwon'twork.

  • Steve (unregistered) in reply to RFoxmich
    RFoxmich:
    How it should have gone: Alan, You are right the customer is experiencing a problem that is preventing them from getting work done, I have moved this ticket over to the hardware support staff. They will keep it open until a new printer is installed. If at that time there are still printing issues please raise them with that staff. <closed>

    Not really a need to let Alan know there is no hardware support staff ticket ...and maybe not even a hardware support staff. Make him feel good that the issue is being resolved and tracked. That's all he really wanted.

    Alan is an idiot but Colin is the prick.

    So your solution is to encourage the clueless idiot?

  • Jesus Christ (unregistered)

    Do the developers get dinged for having too many open tickets, or for having a ticket open too long? If not -- if tickets are purely a communication and record-keeping device between support and development -- then as others have said, the developer could just have noted in the ticket that the problem was a broken printer and left it open until the printer was repaired or replaced. If that was the situation, then he was just being dumb to make a big deal of it. Who cares if support doesn't understand the root cause of the problem? Just leave the ticket open until the problem is fixed, whatever is required to get it "fixed".

    But if the ticket system IS used to "score" the developers, that's a different story. I used to work for a company where various top executives would get a regular report on how many open tickets there were, how long they'd been open, etc and then they'd yell at the project teams for having all these open tickets. It did no good to point out that the ticket was still open because the customer had never replied to a request for more information, or that a fix required a decision about requirements and we were still waiting on a decision from the same manager who was now yelling at us for not getting the ticket closed, or that we had been told not to fix that particular problem because the system was was being replaced by the new-and-improved whizbang system and so it wasn't worth spending time and money to fix it (even though the new-and-improved whizbang system is five years behind schedule with no end in sight), etc etc. Thus there was constant pressure to close tickets, even if the issue was not really resolved. We had to find some justification to close the ticket.

    This is a subset of that whole large category of things that are really good when used as a day-to-day working tool, but that become counter-productive when used as a personnel management tool. Because once the tool is used to evaluate the productivity of employees, the employee's incentive shifts from being "keep the information as accurate as possible" to "keep the information as favorable to me as possible".

  • (cs) in reply to eVil
    eVil:
    There clearly isn't an actual problem here, just some data on a computer that alleges that there is a problem. Colin could have easily just ignored that ticket for a week and moved on.

    Unless Alan is standing by Colin's desk shouting about the issue, then there is no issue.

    Basically, Colin doesn't like Alan, and has accidentally trolled himself by responding to him, when he could have just gone to the kitchen for a nice cup of tea and a biscuit.

    That is unless the employer has some draconian policy against ignoring bugs, regardless of the idiocy of its contents.

  • eVil (unregistered) in reply to RHuckster
    RHuckster:
    That is unless the employer has some draconian policy against ignoring bugs, regardless of the idiocy of its contents.

    Yeah I suppose... but then that's a WTF in itself.

    I'd have still just ignored it, and waited until the draconian policy asserts itself, then tell the draconian policy enforcers that I already resolved it, provide them with the evidence, and then give them directions to Alan's desk.

    I'd probably also offer them one of the lovely biscuits I got from the kitchen, along with a friendly smile.

  • (cs)

    There's too many comments saying it to pick one to reply to, but for those stating it should have been left open and/or handed off to the "hardware support", I got the impression that this company simply sells software. So it would be like, as the developer noted, calling Microsoft to open a ticket with their support and expecting them to keep it open until you get the new printer. If this company does also support the printer then yes it's just a matter of reassigning it to the correct person. If not then there's no reason whatsoever to keep it open.

  • Chad (unregistered)

    I would have left it open and never closed it. Fuck em

  • Sly (unregistered) in reply to eVil
    There clearly isn't an actual problem here, just some data on a computer that alleges that there is a problem. Colin could have easily just ignored that ticket for a week and moved on.

    Unless Alan is standing by Colin's desk shouting about the issue, then there is no issue.

    Not if he have some "reporting" about opened issues : it's always more difficult to explain to a manager why a ticket was left open for more than a week than to close a ticket when it's stupid

  • (cs)

    Where is Steve the Cynic and his GAU-8?

  • Herp (unregistered)

    This is possibly the result of a long history of the IT department forgetting to finish cases because of more urgent work, or ignoring cases and letting them silently disappear. Happens all the time where I work, and it's very irritating.

    Alan H is certainly being a dumb ass here, though.

  • (cs) in reply to bjolling
    bjolling:
    QJo:
    Alan H should have said in the ticket: "Please leave this ticket open until the printer is installed and the customer is satisfied."

    Colin D should not have closed the ticket until the customer's problem had been resolved. Instead he should have said: "Resolution awaiting on new printer to be installed."

    I expect there may have been history between Alan and Colin: the latter thinks the former is a small-minded little pen-pusher who just can't understand plain technospeak and is to be treated with off-hand contempt. Alan recognises this fact and offers, by means of the minimal necessary communication, the egregiously abrupt and arrogant Colin the opportunity to say something that will result in his career prospects to be severely damaged.

    In this context my sympathies lie with Alan. Colin is a 99-octane prick.

    3/10 Would not respond to this troll again
    I'll bite. The ticket should have been marked resolved. The original complaint was that items being printed were coming out distorted. After tracing it to the printer, AND NOT THE SOFTWARE FOR WHICH THE TICKET WAS OPENED TO SUPPORT, it should have been resolved. It is not a bug in the software, it should have been closed.

  • Art (unregistered) in reply to Chelloveck
    Chelloveck:
    Ticketing system? You're lucky! We have to make do with a continuous chain of emails that include all the other emails ever sent in the conversation.
    Easy fix: accidentally copy one of those to a group with about 4,000 names on it, sit back and watch the reply-all storm of people saying "take me off this list" and "stop hitting reply all you moron" (replied to all).
  • (cs)

    I like our (inhouse) bug tracker. It's got its share of WTFs, like not being able to set a new bug status if it hasn't loaded the list of possible statuses (~70) in another frame yet, but quite powerful.

    In this case, I'd suggest the status 'Closed, environment issue'.

  • Chuck (unregistered)

    I'm sure someone has said this but I can't be arsed to read all of the comments:

    The whole problem is that Alan H thought that the bug reporting software was issue-tracking software, or didn't know the difference; and Colin didn't explain the difference to him. Drives me crazy when poor communication yields counterproductive situations like this.

  • neminem (unregistered) in reply to PleegWat
    PleegWat:
    I like our (inhouse) bug tracker. It's got its share of WTFs, like not being able to set a new bug status if it hasn't loaded the list of possible statuses (~70) in another frame yet, but quite powerful.

    In this case, I'd suggest the status 'Closed, environment issue'.

    That is... a lot of statuses. Even if you only had one field, so "closed, fixed", "closed, duplicate", and "closed, not a bug" were three statuses, rather than the logical implementation where "closed" was the resolution and "not a bug" was a separate status... we'd still only have 36 "statuses" under that system, and it's pretty rare that that doesn't cover all our needs. New/confirmed/assigned/resolved/closed, coupled with not fixed/fixed/not a bug/duplicate/can't reproduce/won't fix (usually means "a bug, but not -our- bug, bother the software whose bug it is." Occasionally means "not worth our time.")

  • Ken B (unregistered) in reply to Ben Jammin
    Ben Jammin:
    Accalia.de.Elementia:
    ZoomST:
    Ticket 268744
    =============
    

    Open 19-Feb-2013 09:45 Opened by Colin D

    Spoke to Barry and Denise. Found an issue in the Initrode development: Alan H is defective. Must be replaced or eliminated. Customer agrees. --

    StatusChange
    Assigned       19-Feb-2013 11:16 Assigned by Colin D
    ----------------------------------------------
    Spoke to "One Mad Man" Tony K down at the docks. He is dispatching some of his boys to permanently resolve the issue with Alan H.
    --
    StatusChange
    

    Reopened 19-Feb-2013 15:16 Opened by Colin D


    Customer saying Alan H. is leaking "some sort of fluid" and is alternating between between making "annoying, sobbing" and "Oh please, God, No!" sounds.

    --

    StatusChange
    
    Closed         20-Feb-2013 06:30 Closed by "Old Man" Tony
    ---------------------------------------------------------
    
    Behavior is as expected, and within normal parameters.
    --
  • cesarse (unregistered)

    Can I apply for a job in your company?

  • The Captain (unregistered)

    What we've got here is failure to communicate. Some men you just can't reach. So you get what we had here last week, which is the way he wants it. Well, he gets it. I don't like it any more than you men.

  • (cs) in reply to neminem
    neminem:
    PleegWat:
    I like our (inhouse) bug tracker. It's got its share of WTFs, like not being able to set a new bug status if it hasn't loaded the list of possible statuses (~70) in another frame yet, but quite powerful.

    In this case, I'd suggest the status 'Closed, environment issue'.

    That is... a lot of statuses. Even if you only had one field, so "closed, fixed", "closed, duplicate", and "closed, not a bug" were three statuses, rather than the logical implementation where "closed" was the resolution and "not a bug" was a separate status... we'd still only have 36 "statuses" under that system, and it's pretty rare that that doesn't cover all our needs. New/confirmed/assigned/resolved/closed, coupled with not fixed/fixed/not a bug/duplicate/can't reproduce/won't fix (usually means "a bug, but not -our- bug, bother the software whose bug it is." Occasionally means "not worth our time.")

    That, and variations, and enhancements/doc bugs are tracked via separate statuses (though those lists are smaller).

  • Ken B (unregistered) in reply to Jesus Christ
    Jesus Christ:
    Do the developers get dinged for having too many open tickets, or for having a ticket open too long? ... But if the ticket system IS used to "score" the developers, that's a different story. I used to work for a company where various top executives would get a regular report on how many open tickets there were, how long they'd been open, etc and then they'd yell at the project teams for having all these open tickets. ...
    I've seen telephone support with "metrics" like that, too. Someone who got the customer off the phone fast, even without resolving the problem, was perceived as "better" than someone who took the time to actually, you know, fix the problem.

    Better to have the customer spend 2 hours over 20 phone calls than to have a single 15-minute call.

  • (cs)

    I get the feeling that these two people have a history. I bet they even avoid eye contact with each other.

  • Ken B (unregistered)

    As a software developer, I've had my share of such "bug" reports. Fortunately, I've never had to deal with someone like Alan H., and "hardware issue -- not a bug" was usually sufficient to have the item remain closed. Sometimes, a brief description of why it was a hardware problem was required, but that's it.

    Example:

    "Bug":

    Vertical lines on graphics boxes on ${TERMINAL_MODEL} are not connected.

    "Solution":

    ${TERMINAL_MODEL}'s graphics character set draws vertical lines with gaps. Not a bug.

  • Z (unregistered)

    For many years at the company I work with now, the home-grown helpdesk application also did double-duty as the software feature and defect-tracking system. Among other abominations, this led to any open issue on a program (feature request, bug, cosmic disaster) being referred to as a 'point' (i.e. 'that is one nasty point you have open in the Checkout program), because 'Point' was the label used by the original programmer on the issue reporting form. Thankfully, this system has been long retired, although some of the old-timers will still sometimes forget themselves and refer to bugs as 'points'.

    I'm guessing that Colin is fighting a losing battle with a similar system; a catch-all program that logs everything from new furniture requests to the development teams plans for bringing about the rise of Skynet. After all, it worked when there were only 20 employees in the company; why shouldn't it work just was well when there are 1000?

  • instigator (unregistered) in reply to Mike
    Mike:
    The ticked was sort of kept open. The status pinged on and off 'resolved' but only at the end was it 'closed'. Though oddly the other status was 'reopened' so resolved is clearly not open either.

    So, TRWTF is bad issue workflow.

    When is an open ticket not an open ticket? When it's a jar!

    No. That workflow is pretty standard. The assigned developer resolves the bug. If it is fixed, the reporter closes it. If there are still problems, the reporter reopens it. Resolved is kind of a limbo state. Not really open, not really closed.

  • PRMan (unregistered) in reply to QJo
    QJo:
    Alan H should have said in the ticket: "Please leave this ticket open until the printer is installed and the customer is satisfied."

    Colin D should not have closed the ticket until the customer's problem had been resolved. Instead he should have said: "Resolution awaiting on new printer to be installed."

    I expect there may have been history between Alan and Colin: the latter thinks the former is a small-minded little pen-pusher who just can't understand plain technospeak and is to be treated with off-hand contempt. Alan recognises this fact and offers, by means of the minimal necessary communication, the egregiously abrupt and arrogant Colin the opportunity to say something that will result in his career prospects to be severely damaged.

    In this context my sympathies lie with Alan. Colin is a 99-octane prick.

    One lacks mental skills, the other lacks social skills. Why hate on one over the other?

  • (cs) in reply to Tom
    Tom:
    How it should have gone is that it should have stayed at "resolved" by the customer ordering a working printer, then set to "closed" or reopened, as the case may be, after the new printer is installed.

    Alan's both idiot AND prick, for continually opening a resolved ticket.

    Get real. You can't set a ticket "resolved" unless the issue has genuinely been resolved - in this case, by the new printer being installed. Once the customer has acknowledged that the issue has been resolved, then and only then do you close it.

    Colin is not a prick. He's an utter fucking cunt and he ought to be flying out of the door at a sizeable fraction of the speed of light. A complete fucking shithead.

  • instigator (unregistered) in reply to Chelloveck
    Chelloveck:
    Tim:
    What I want to know is what kind of ticketing system gives you a nice readable history like that?

    Ticketing system? You're lucky! We have to make do with a continuous chain of emails that include all the other emails ever sent in the conversation. Half the people top-quote, half bottom-quote, and nobody trims headers. Oh, we dream of having a crappy ticketing system!

    Luxury!!! We would kill for a simple plain text email chain. We track our bugs on a Lotus spreadsheet on an external hard that we pass between cubes. If we're lucky, the hard drive is at our building!

  • Tim! (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Tom:
    How it should have gone is that it should have stayed at "resolved" by the customer ordering a working printer, then set to "closed" or reopened, as the case may be, after the new printer is installed.

    Alan's both idiot AND prick, for continually opening a resolved ticket.

    Get real. You can't set a ticket "resolved" unless the issue has genuinely been resolved - in this case, by the new printer being installed. Once the customer has acknowledged that the issue has been resolved, then and only then do you close it.

    Colin is not a prick. He's an utter fucking cunt and he ought to be flying out of the door at a sizeable fraction of the speed of light. A complete fucking shithead.

    Not sure if troll...

    You can set a bug "resolved" if the issue is not a bug in the product, your bug tracker is intended to track product bugs, and there is a completely different system (note "An issue was raised with IT Support Desk (SUP88373)" for tracking customer support requests. You generally do so with a substatus like "Can't repro" or "External".

    The bug was properly resolved. Alan H should have immediately Closed it, and tracked the status of the customer's printer acquisition through the appropriate channel.

  • (cs) in reply to instigator
    instigator:
    Chelloveck:
    Tim:
    What I want to know is what kind of ticketing system gives you a nice readable history like that?

    Ticketing system? You're lucky! We have to make do with a continuous chain of emails that include all the other emails ever sent in the conversation. Half the people top-quote, half bottom-quote, and nobody trims headers. Oh, we dream of having a crappy ticketing system!

    Luxury!!! We would kill for a simple plain text email chain. We track our bugs on a Lotus spreadsheet on an external hard that we pass between cubes. If we're lucky, the hard drive is at our building!

    We are doing this on a whiteboard and we come and click photo of it with cellphones.

  • Sam I am (unregistered)

    Wouldn't you hate to be that customer who keeps getting pestered about his broken printer?

  • C-Derb (unregistered) in reply to Ken B
    Ken B:
    Jesus Christ:
    Do the developers get dinged for having too many open tickets, or for having a ticket open too long? ... But if the ticket system IS used to "score" the developers, that's a different story. I used to work for a company where various top executives would get a regular report on how many open tickets there were, how long they'd been open, etc and then they'd yell at the project teams for having all these open tickets. ...
    I've seen telephone support with "metrics" like that, too. Someone who got the customer off the phone fast, even without resolving the problem, was perceived as "better" than someone who took the time to actually, you know, fix the problem.

    Better to have the customer spend 2 hours over 20 phone calls than to have a single 15-minute call.

    Years ago, I spent some time working for JC Penney in their catalog sales department, taking phone calls from people who wanted to place a catalog order. We had a goal to keep the calls under 3 minutes long, which was usually pretty easy to do. However, just to be safe, I devised a plan to keep my stats low.

    If I immediately received another call after the previous call ended, I knew customers were on hold waiting for the next available CSR. But if there was a longer than 10 second pause between calls, I knew that person had just barely dialed in. So, I would pick up the call and then hang up on them. I assumed they would figure they dialed wrong or something, and probably just dial back in. I didn't do it on back to back calls, in case it was the same person, and really I didn't do it that often. But five 1 second calls grouped with 45 120 second calls was enough to keep me at the top of the rankings.

  • IP-guru (unregistered)

    Clearly the written medium is failing to communicate correctly causing confusion.

    fortunately I have a piece of equipment on my desk that can usually solve these failures is a mater of moments

    What is it? A Telephone!

    "Its Good to Talk!

  • HardwareGuy (unregistered)

    The company I work for has a unique (I hope) system for preventing tickets from staying open too long. The ticket must be updated at least once a week. Not just any update will do, however. The "Waiting on" field must be reassigned between support and the user. If internal support is waiting for an answer from the software vendor's tech support, the internal support must still reassign it to the user, even though it isn't waiting on the user.

    What happens if the ticket goes a week without playing this little game? Does the ticket get escalated because it is taking too long to resolve? Noooooo.... The system assumes that if the ticket hasn't been updated, that the user no longer has a problem, and automatically closes the ticket.

  • Simon (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Get real. You can't set a ticket "resolved" unless the issue has genuinely been resolved - in this case, by the new printer being installed. Once the customer has acknowledged that the issue has been resolved, then and only then do you close it.

    Would you prefer "Cancelled - not a bug?" Because if it's been logged as a software defect but found to be a hardware problem, we'd cancel it in an instant. They can re-open it if the problem persists after the hardware is replaced...

  • Norman Diamond (unregistered) in reply to Jesus Christ
    Jesus Christ:
    Do the developers get dinged for having too many open tickets, or for having a ticket open too long?
    God knows.

    Oops ... wait ...

  • Earo (unregistered) in reply to PolarityMan

    If that was the case, then Alan H should have logged that in the ticket. Anyone who reopens a ticket without at least the courtesy of saying why, or replying to the answers he has been given, is an idiot.

    PolarityMan:
    This could have been down to a lack of joining up 2 parts of the business. It's not uncommon for a customer to want a ticket open somewhere until theyre actual problem is resolved. My guess is that in this case it ended up on a bug tracker for some specific product instead of somewhere that deals with hardware and recquisitions etc.

    Nedded one of those 2 guys to take ownership and sort things out.

  • JustSomeGuy (unregistered) in reply to IP-guru
    IP-guru:
    Clearly the written medium is failing to communicate correctly causing confusion.

    fortunately I have a piece of equipment on my desk that can usually solve these failures is a mater of moments

    What is it? A Telephone!

    "Its Good to Talk!

    Actually, I find that the modern telephones aren't really heavy enough to crush the skulls of my nemeses (sp?). That's why I keep a cricket bat on my desk.

  • Gigaplex (unregistered) in reply to Art
    Art:
    Chelloveck:
    Ticketing system? You're lucky! We have to make do with a continuous chain of emails that include all the other emails ever sent in the conversation.
    Easy fix: accidentally copy one of those to a group with about 4,000 names on it, sit back and watch the reply-all storm of people saying "take me off this list" and "stop hitting reply all you moron" (replied to all).
    Bedlam DL3
  • WtfIsACheck (unregistered)

    Reminds me of the few occasions I hard to work with an Aspie.

    Pray that someone else tells you about the condition before, otherwise you will get in very, very awkward situations.

  • (cs) in reply to WtfIsACheck
    WtfIsACheck:
    Reminds me of the few occasions I hard to work with an Aspie.

    Pray that someone else tells you about the condition before, otherwise you will get in very, very awkward situations.

    A lot of us keep quiet about our condition for fear of being discriminated against when we apply for our jobs. (Coping techniques have taught us the techniques for hiding this aspect of our personality.)

  • Cereal Killer (unregistered)

    there are 2 possible reason why Alan behaves that way:

    A) Alan H is an idiot who don't even look through the ticket history before re-opening the ticket or call the customer for follow up. There are more of such people on this planet than you think.

    OR

    B) Alan H is required to follow up the customer after ticket is closed and is required to re-open the ticket if the issues is not resolved.

    I agree with previous posts, the real WTF is the communication skills for both parties involved and the management's idea of performance tracking via the ticketing system.

  • Anon (unregistered) in reply to Chelloveck
    Chelloveck:
    Tim:
    What I want to know is what kind of ticketing system gives you a nice readable history like that?

    Ticketing system? You're lucky! We have to make do with a continuous chain of emails that include all the other emails ever sent in the conversation. Half the people top-quote, half bottom-quote, and nobody trims headers. Oh, we dream of having a crappy ticketing system!

    And don't forget about the chain of emails all of which have "This communication, including any attachments, may contain information that is confidential and may be privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation." (which no one trims off either?) (Like that sentence carries any legal weight with it anyway, it's a waste of electrons.)

  • Anon (unregistered)

    We had a bouncing bug like this with one of our customers. We'd introduced a new version of an application to be compatible with their new (completely incompatible) back-end system. They raised a bug that, when the thin-client software was restarted, it didn't go back to the main menu. The tester insisted that the old software had done this - even though the application was designed to, and had always, directed the client back to the same screen that the user was on when it was closed down.

    The tester would absolutely not accept that this was the case, but refused to actually compare it to the old system, and refused to close it. So we had this bug hanging around and being mentioned in conference calls, until it was the only unresolved bug left. Eventually the customer's project manager accepted that it was not actually a bug and stopped mentioning it, but it's still open in their bug tracking system as far as I know.

    That project manager has now left, so I live in fear that the zombie bug will one day come back to haunt us...

  • (cs) in reply to Wally
    Wally:
    This doesn't quite count as a representative line because, well, it is two lines. But still:
            if($fileObject->{isOk}){
                if($fileObject->{isOk}){
    Should I submit a ticket to my printer company? I think the printer is wasting ink every time I print this program's source code.
    For people who don't know Perl, there's a double WTF here; the
    ->{isOk}
    syntax is syntax for accessing the fields of an object directly, without going via accessor methods. (Most likely because there are no accessor methods on the object, in this case.) So not only is the line written twice in a redundant way, but one of the lines would be WTFy by itself.
  • IntentionalPrick (unregistered)

    I had a similar experience, but rather than get angry I gave the guy a time-out.

    switch(config)# int eth 1/g10
    switch(config-if)# shutdown
    
  • (cs) in reply to Anon
    Anon:
    We had a bouncing bug like this with one of our customers. We'd introduced a new version of an application to be compatible with their new (completely incompatible) back-end system. They raised a bug that, when the thin-client software was restarted, it didn't go back to the main menu. The tester insisted that the old software had done this - even though the application was designed to, and had always, directed the client back to the same screen that the user was on when it was closed down.

    The tester would absolutely not accept that this was the case, but refused to actually compare it to the old system, and refused to close it. So we had this bug hanging around and being mentioned in conference calls, until it was the only unresolved bug left. Eventually the customer's project manager accepted that it was not actually a bug and stopped mentioning it, but it's still open in their bug tracking system as far as I know.

    That project manager has now left, so I live in fear that the zombie bug will one day come back to haunt us...

    You just always give that one bug to the FNG to test their people skills until one of them succeeds.

  • Craig (unregistered)

    Unfortunately, this sounds a lot like the thought processes of our help desk...

  • EB (unregistered) in reply to Tim
    Tim:
    What I want to know is what kind of ticketing system gives you a nice readable history like that? The last two my employer bought (for mega$$$$) have a tiny postage-stamp sized text box for the meat of the ticket (after 217 status and classification dropdowns) so you have to scroll like crazy and read one word at a time. Plus, after about 10 words of each previous note, it just adds a "..." and you have to click a link (wait 6 seconds) to read the rest of the note, then go BACK (wait 6 seconds) to advance to the next note -- in reverse chronological order.

    I think it is from the "no one reads anything anyway" school of web design.

    Wow, wonder if we worked in the same place. Or perhaps Microsoft managed to sell that SCSM system to some other poor bugger as well.

    Captcha: Eros... Definitely not something I'd normally associate with SCSM.

  • Neil (unregistered) in reply to Earo
    Earo:
    If that was the case, then Alan H should have logged that in the ticket. Anyone who reopens a ticket without at least the courtesy of saying why, or replying to the answers he has been given, is an idiot.
    PolarityMan:
    This could have been down to a lack of joining up 2 parts of the business. It's not uncommon for a customer to want a ticket open somewhere until theyre actual problem is resolved. My guess is that in this case it ended up on a bug tracker for some specific product instead of somewhere that deals with hardware and recquisitions etc.

    Nedded one of those 2 guys to take ownership and sort things out.

    Egads, the top-posting bug has reached readers of The Daily WTF :-(

  • Unpolite (unregistered)

    So many nice people... If I was there it would end like that

    IF YOU REOPEN IT AGAIN DI**T I'LL COME TO YOUR OFFICE AND START KICKING YOUR HEAD UNTIL YOU FIGURE OUT HOW TO THINK WITH IT, NOT WITH YOUR A.

Leave a comment on “I'm Sensing Some Tension”

Log In or post as a guest

Replying to comment #:

« Return to Article