Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Getting the most from your Support Engagements

Thoughts from a former Support Backline Representative
Created: 25 Mar 2014 • Updated: 26 Mar 2014 • 3 comments
Thomas Baird's picture
+8 8 Votes
Login to vote

After leaving support a couple of weeks ago to join a consulting firm called XCEND (shameless plug:, I've been pondering things I left behind and thought it might be useful to others to get a "glimpse" of how things work inside Support.  However, I think it'd better to simply tell you how to make things work better for you when you need to work with Symantec. (Note to self - that includes me now!)  I think looking at your experience with Symantec Support in 4 areas will be sufficient:

  • Preparing for your support experience
  • Your Relationship with your Support Rep
  • Remaining in control of your issues
  • Proceed with Caution

In all of the above, I will be using in a very biased way my own personal experiences from the inside looking out.  Everyone reading this knows what it looks like from the outside looking in, so this is intentionally a biased view from the other side, along with advice on what may help you.

Preparing for your support experience.

One of the biggest problems I've seen in support incidents is the lack of understanding of a problem.  This may happen on either side of the connection - either the customer doesn't know what's wrong (sometimes they don't even know what they want - rarely though), or the engineer working the issue doesn't understand the problem.

Either way, it causes delays, misunderstandings, and often multiplies problems instead of resolving them.  What a waste!

From an insider's view, when a customer doesn't know what's going on - some less than positive things can happen.  USUALLY you get a sympathetic ear.  That really is the norm.  However, there are times when the tech might be tempted to belittle the customer or look down at them.  Repeat offenders get a reputation and are avoided.  And the worst I've seen is the "blind leading the blind" scenario where neither customer nor tech knows where they're going.

These don't happen often, but you can prevent it!!

How?  Know your situation before going into any engagement with support.  KNOW what you've done, what you're doing, and what you've tried to do.  Know what you searched for.  Remain in control of the call (kindly) by being confident in what the situation is.  You may learn you're wrong, but at least YOU don't go in blind.

A short example:

Let me share a brief example of a call I've actually seen before. As you read the rest of this document, think back on this and you'll see many more mistakes than I point out here.

  • Customer:  "Imaging is broken!  I can't capture or deploy images!"
  • Tech: "Let's take a look at your PXE settings..." 

<sigh>  Mistakes on both sides...

First, not EVERYTHING is broken.  Take the time to know what and where.  I can't tell you how frustrating it is to hear that from a customer because you KNOW that 99.9% of the time it's flat out false.  It's like my daughter saying "My life sucks!  You're always so mean!" while we're at the amusement park and I just told her she can't have a third run at the games.  Really?  Always so mean?  The complaint is WAY too generic.  If you're frustrated (duh- you just called support and who does that by choice??) it's tempting to just air that frustration, but trust me, it doesn't help the call.  Take a deep breath, calm down (before you call in), and find out WHAT is broken.  At what step do things fail (take notes)?  Have you tried other things around that step (more notes)?  Looked at the KB or Connect?  Document it, and go in with a direct statement like "When I run the Sysprep step of my imaging jobs..." or "I keep getting an error in the console when I capture an image that says..."  MUCH better!

Second, STOP your engineer from just jumping to conclusions!!  Why are they looking at PXE?  Should they be?  Who determined that was the failure spot and needs fixing?  Was a basic discovery done?  Same thing applies to them as you: they need to take a breath, calm down, and do initial discovery.

Your Relationship with your Support Rep.

This should be taken as seriously as your relationship with Sales.  You don't want to tick-off your sales rep so you'll get the best deals, right?  Same goes for your technical rep(s). You DO want to be firm and forceful with Sales where necessary / possible to ensure they know what you want and what you expect.  Same for support.  You DO want to be sure to communicate your concerns with your sales rep.  Same with support.

Take this seriously.  Build a relationship and rapport with them.

Why?  Because we're people too!  We have stressful jobs too.  And the simple truth is, when a support rep is your friend, they bend over backward "just a bit" more than they would otherwise.  Remember the above discussion about being prepared?  One way to prevent looking stupid and having your rep talk down to  you is to be friendly, communicative, patient, and personable with your rep.  BOTH of you want the call over ASAP.  Take the time to know they're a person too, and let them know you are.

In reality, like Sales, this is the responsibility of the support rep.  But, unlike sales, the rep usually has no direct reward for taking your call, and therefore has less incentive.  Reality: they don't always care, even if they should, or usually do.  Make them care.  Be in control of your destiny.

A few key take-aways:

  • The higher up you go in escalation, the busier the rep is.  Be prepared to wait.  Another way to translate that is: don't escalate unless you have to.
  • Belligerence is best left for management.  It doesn't make friends with Techs.  Consider how you feel if you get pressure to make decisions you can NOT make.  You want people to talk to whomever can actually do something about it.  Remember your tech is in the same boat.
  • If you're upset, TALK to leadership.  Don't hold it back and keep it personal.  Be professional, but let your feelings be known.
  • TALK to your sales rep if you're not getting what you need. They may or may not be able to help, but what do you lose?
  • Treat your Support Rep as an equal, and expect them to do the same, even if you have to say exactly that out-loud.

Remaining in Control of your Issues

There are several facets of this that are worth noting here.  To simplify, I'm going to bullet-list this.

  • Keep things simple and separate.  Don't try to get your support rep to fix everything that is broken all at once.  This is a great way to get sidetracked from what is most important to what is least and/or easiest.  Keep a list if there are multiple issues, and ask your rep to open new cases if you need to.  You keep on focus, and your rep will too.
  • Ask Pertinent Questions.  Don't let your rep run away with you without knowing what they're doing or why.  If something doesn't make sense, ask. Don't be shy. They may know what they're doing but you have a right to do so as well.  And if they're guessing, make them admit it!  At least you'll be fully aware.
  • Take Backups.  OK - most techs don't make mistakes.  But what if you're the lucky one?  Don't get caught being unprepared.
  • If you have consultants (yeah, that'd be me now), include them in your call so they can both double-check the recommendations AND possibly ask more questions you don't think about.
  • If your consultant is calling in, ask to be included and participate.  Be sure that any information going to your partner isn't filtered before it reaches you.  Remember, Symantec and your Consultant, though partners, have differing agendas: Symantec wants to sell you product.  Your consultant wants to sell you hours and work.  YOU stay involved in both so you know what is best for YOU.
  • Ensure your engineer takes appropriate steps and actions.  Did they do proper discovery of your problems?  Did they ask relevant questions?  Did they listen as you answered?  Did they escalate - when - to whom?  Do they have a date to get back to you?  Did they document their issue to Dev?  What are the new ticket numbers they created?  Expecting this kind of information keeps you in control.

Proceed with Caution

This final section I had a difficult time naming.  I don't want to sound negative in any way here, but I'm not sure any better way to say this, so here we go.

The simple truth is that not all problems have cut-and-dry answers.  Not all of the have known answers.  That means there's at least a chance that your issue involves some guessing from Support.  It's a part of troubleshooting that cannot be skipped.

Your support rep will attempt to be smart about this, but they cannot and do not know your environment, AND they do not know everything about their own product.  YOU are responsible for what happens in your location, not them.  So how do you manage this guess-work?

  • If it stinks, call it out.  If what your rep is saying doesn't sound right, say so - challenge him or her.  If they're legit, they'll explain.  If they can't, then you have a reason to escalate.  YOU deserve the best you can get.
  • Always do backups
  • Be wary of things like "Let's reinstall that" or "Maybe if we uninstall..." or "Here, let's try..." statements.  That doesn't mean they're always invalid, just proceed with caution.  Some engineers like to try a reinstall route over finding out what actually broke.  Granted, a reinstall may fix something, but what if the same thing breaks again in a week?  That's not always a fix, so be wary.
  • If the engineer is "poking around" make sure they don't change things without your approval.
  • Challenge requests to upgrade.  "If it ain't broke, don't fix it" is a good mantra to live by.  Upgrades can break things that aren’t broken.
    • A word of caution on this.  Development often is limited on what they can actually fix in older versions.  Also, it is a perfectly valid thing to think that the latest service pack might have fixed something if a fix was made to another similar area.  Sometimes, the only GOOD option you have is to move forward with a hotfix or rollup in order to validate to Dev that this is something they need to work on.
  • Ask your rep to try it themselves.  Why not?  If possible, and they see it on their system, then they can poke around on their system instead of yours.  Right?  That's gotta be good for everyone.


Do NOT walk away from this discussion thinking support is all messed up.  Some of the very best people I've EVER worked with are still over there at Symantec taking your calls.  I left so I could learn and grow in new directions, not because I hated working there.  It was an honor to be a part of that organization and those that know me (worked with me) should know I loved my job!!

But I saw situations that could have been handled better, customers that could have gotten questions answered faster, and yes, mistakes made.  AND I met customers who knew how to get what they needed - and they did!  Not just big ones either (which is everyone's assumption).  One, for instance, had less than 300 clients but wow - when they spoke, everyone listened.  Why?  Because they knew how to work their relationship with Symantec so much better than others.

Good luck to all the rest of you!!

Comments 3 CommentsJump to latest comment

skhs's picture

Thomas congrats on new role, this is good information. I always recommend beofore calling the support, make sure get the screen shot, logs from Client and Server as needed, any chnages done , any environmental issues etc. to expediate the process and help support to understand the issue. 

Are there any questions or material you would recommend for customers to provide when call that will enable support to reslove issue faster?

Thanks for sharing this info. 

Login to vote
ianatkin's picture

Nice succinct post Thomas, and one I think is important reading for Altiris Administrators.

@skhs: I think you've pretty much got it pretty much well covered.

In my experience to date, generally support will ask for,

  1. Server logs (Windows logs as well as Altiris Logs)
  2. Logs from affected clients (if you can)
  3. Screenshots highlighting the problem (if applicable)
  4. Steps to reproduce (if applicable)
  5. Impact (how serious is this for you.. be honest...)
  6. Versions of product installed
  7. Versions of agent distributed

I sometimes will add wireshark traces if I think they'd be useful. I would highly recommend that ALL Altiris administrators help themselves by creating scripts to,

  • Gather logs from clients remotely (agent logs + windows logs)
  • Create log archives from the server

This means that when you experience a problem (which you'll be generally under pressure to resolve) the act of gathering support logs is then only ever a few clicks away. Which means that opening a case  on mysupport is only ever a 10 minute task.

If you use the support service right, it really does work.

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

Login to vote
Tomasz Wozniak's picture

Thanks for sharing your thoughts.

I have had opened about 40 cases with Symantec Support in the last 18 months.

The experience really varied from totally satisfied to barely acceptable.

In one case the tech rep undestood the issue and was able to provide the fix within 1 working day.

In other cases I did not get the call back even after 5 days since the ticket was opened, misunderstanding of the nature of the problem , focusing on closing case not resolving the problem etc.

Often I wasted first weeks trying to get through first line to someone who had idea about how the product works. Then usually the things got back on the right track with back desk engineer.

Login to vote