Hi Eric, I know your original post was a <rant>, but I wanted to respond because as someone who lives, eats and breathes my customer's problems (just like my fellow TAC engineers) it hits hard when I hear about something like this. As others have mentioned, there are escalation paths within and outside of TAC to assist you when you do not feel your problem is getting the attention it needs. But I don't think that really addresses your rant. All I can say is that engineers do need to take time off occasionally (whether sickness, travel or vacation), but it should not be something that you would experience regularly.
This much I know is true, working in TAC isn't so much of a job as a life choice. We are here because we want to help people (our customers) and we like solving complex challenging problems. Our customers come first (often at the expense of many other parts of our life). With Respect, David White. Cisco TAC On 4/30/2015 8:47 AM, Eric Van Tol wrote: >> I think it's because the same engineer is also working on my cases, and >> since he's busy not working for me, he has no time to be not working for >> you. >> >> (I have a case that is quite straightforward, and after the engineer built >> a lab setup that didn't show the problem, most likely due to "using wildly >> different IOS versions", he just stopped talking to me - maybe he's busy >> sending vacation messages to everyone else...) > This was hilarious, thanks (the first paragraph, not the second). > > Anyway, I would like to say that I'm glad to see it's not just me. Is it > really possible that so many TAC engineers are going on vacation so soon > after taking cases? It's absolutely ridiculous the amount of times I've had > this happen to me. What are the actual odds that this is just coincidence? > > As for asking for a new engineer to take the case, that's a big problem for > me. Usually when I open a case, it's something that I've spent hours, days, > or weeks on, simply because I've exhausted all possible solutions on my end > (Opening cases with TAC is a last resort). I have a difficult enough time > telling the first engineer what the problem is, what I've done to > troubleshoot it, and so on, that I don't want to have to go through the same > process with another one. > > -evt > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
