There are times when the only way to resolve an issue is to deal directly with Salesforce Support, such as when you need to ask them to adjust a soft limit for an organisation.

This can be a frustrating experience (see What's more helpful than Salesforce Customer Support?).

  • When raising a support case, what approach is the most effective?
  • What information should I supply in the case notes by default?
  • Are there any steps I should undertake to speed the process up?

For example, when I've tried calling Premier support I've found they have trouble understanding my accent and the case notes they create are often incoherent. To be fair it may be my fault as a New Zealander, but I feel like a Scotsman in a voice activated lift.

I suspect there are other issues at play here as well. The client Org User records I often work in will be in another time zone, say Pacific Standard Time where I'm on NZ Standard Time. I'll end up exchanging case notes with support every 12 hours or getting a phone call at 8 pm. How important is the data in the user record that raises the case?

  • 2
    If you ended up here because you're having a bad day with Tech Support and somehow the Scotsman didn't make you laugh, try Shibboleet. Commented Aug 23, 2012 at 1:44
  • First off, I loved the Scotsman bit. What I've always found frustrating with support is that I have to explain the problem multiple times to different support people. I get the absolute impression that they either don't take notes about the calls or they simply don't read the notes. That drives me nuts. It's a waste of everyone's time. Commented Aug 23, 2012 at 13:24
  • 2
    They don't read the notes most of the time. You're lucky if the even fully read the original description. Even though I always indicate I've granted login access and list the org Ids I usually get asked to grant login access and/or for the org ID. Commented Aug 24, 2012 at 18:08
  • 1
    Interesting, I was contacted by the Director of Technical Support at salesforce.com to provide feedback on this question. Nice to know they are listening. Commented Oct 25, 2012 at 22:33

4 Answers 4


Here are the steps I usually take:

  1. When creating a case, always grant login access to Salesforce support for any orgs involved in the issue and state that in the case description along with the org ID of any orgs involved.
  2. If it's a coding issue, simplify the code as much as possible and re-create the issue in a clean Salesforce instance so there are less factors for support to have to rule out.
  3. Describe the issue as clearly as possible, only including pertinent information.
  4. Respond to Salesforce support e-mails and calls as quickly as possible. If you're lucky you'll catch them before they move on to their next case. Otherwise, who knows how long it'll take for them to respond to your response.
  5. Do NOT let the support rep close the case if you don't feel it's been resolved. If they do, ask them to re-open the case and if that's not done, create a new case asking for the old case to be re-opened, giving the old case number in the case details.
  6. Post the issue on the forums as well, you might get it resolved faster that way. In fact, that may be your only option now if you haven't purchased a higher tier of support.
  7. Post the issue here.
  • 4
    Actually, Step #2 should probably be the first step as every now and then you'll solve your own issue when you're simplifying the code. I did that just a little while ago. :) Commented Aug 23, 2012 at 3:01

I usually try a variety of the below:

  1. State my time zone and the hours that I work
  2. State that I don't respond to phone calls as the issue is too complex and my phone line is bad quality
  3. Write out the issue and the steps needed to be taken to solve it - then drip feed the parts to support to avoid confusion.
  4. Be incredibly precise about what I actually want - which includes the field and object names, dashboards setting etc.

I find that the following don't help or are a bad idea

  1. Linking to forum or other resources that provide most of a solution
  2. Having too many cases open at once - you get overwhelmed by random people calling and quoting odd numbers - and the emails are very user unfriendly if you are trying to figure out which refers to which case.
  3. Complex problems where the problem you end up solving is not the one you started with
  4. Relationship building - the script kills any spontaneity and just disrupts the call plan for them (which is a comment on the process not the individuals)

might not be the best way, but I usually find that being firm and asking for the manager if the front line rep doesn't have the ability to troubleshoot your issue or tries to fluff you. keeping an even tone and using your best logic seems to work every time, even if it takes an hour.

The point of front line support is to get you off the phone, you have to stick to your guns.

  • 2
    A good point. Once I get past the first tier of support the situation usually improves and the person becomes much more knowledgeable. Commented Aug 23, 2012 at 21:38

Daniel, We've had similar experiences with Premier support where they are not understanding our problem (not due accents though). I've found that dealing directly with your Customer Support Manager (CSM) or with your Sales Account rep is very effective. The Sales AE knows that if you're not happy and aren't getting your issues resolved, ultimately you "might" not renew.

In addition, I would talk to your Sales AE and ask that you're support calls be routed to a support desk either in your time zone, or closer to in order to help with the timing of responses (and delays that can cause).

Hope that helps!

  • The time zone issue is tricky, as the orgs in question typically belong to clients who are several time zones away. Moving the support closer to my time zone would be great for me, but would cause issues for anyone else in that company. Commented Aug 23, 2012 at 21:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .