Skip to Content

Give Support a Chance

My first job in planet SAP was a Service Desk Analyst. I was thrown in the deep end and our team had a rule: you stayed on the phone and solved the caller’s issue. Here’s me thinking (with all my university education) hard is it is to answer a phone call, tap away at a few items, give them an answer and move onto the next call?

wrong.PNGMy first phone call starting with me exuding an abundance of confidence. Suddenly all these foreign terms were thrown at me along with a bunch of transaction codes and the user’s interpretation of the issue. Something about they can’t do a GI as they are getting a -10 error but there is stock in the warehouse as they can see it in front of them and PR and IR are all done as well as the vendor has been paid. I was lost! Immediately, I put the caller on hold and turned to my mentor – arggh what do I do?!? I’m told to ask all these questions: Ask them what’s the purchase order number? Ask them if they have received the stock? Have they done the goods receipt? With a few pen and paper calculations and help from my mentor we were able to close out that call. Lesson to the caller: you cannot issue goods if you have not yet receipted them into the warehouse (who would have thought!).


This pattern followed through over quite a few months. But eventually I learned to ask the right questions. Being in a support team taught me an important lesson to use in other jobs: how to obtain valuable information via asking the right questions. Asking the right questions enables you to identify the actual issue and solve it.

I continued in my role, suddenly thinking I was this expert rock star (my inner Gen-Y shines through sometimes). Then I got a phone call from a lady from a country region who was nearing retirement. She did not grow up with computers at home like I did. I did not have remote desktop access to see what she saw so the entire information gathering activity was over the phone. She was stressed and did not know what to do. She did not know what a mouse, monitor or keyboard was. I needed her to email me a screen shot of her error message.  I spent over an hour in a failed attempt to obtain. I started with describing the picture in front of her (aka monitor); I then had to describe the clicky things at her fingers (the keyboard) and step her through the squarish box that says ‘ESC’, followed by the F1 to F12 and then finally a ‘Print Scr’. I tell her to press that last button and explained that she just took a photo of her picture and now we need to “print it” and then send it to me. We got as far as saving the file and she was sooooo close to completing the email that she became overwhelmed, burst into tears and told me her supervisor will call me tomorrow to provide the details. I felt terrible. The following day it took about 10 seconds to get the error message and give her supervisor the solution.


Support taught me patience, empathy and a better understanding of the end user. Support taught me to alter my communication style to my targeted audience. I remember that phone call so well as she is the type of user I think of when I design my solutions.

After a few years in some project roles, I found myself back in Support land. It was less foreign – no longer a planet but still a different country. I eventually became a team leader with members spread across four countries for a follow the sun model support model. Each day I would write down my top priority to do list. As soon as I got to my desk and opened my inbox in the morning (if I had not received a phone call at some ungodly hour in the middle of the night) my to do list would be parked to the side as I was reacting to whatever critical issue had occurred – funnily enough the number that would be teething issues after a release to Production. My day would be taken up responding to issues outside of my control. I would get to the end of a long day and my ‘to do’ list would not have an item crossed of. I knew my priorities on the planning side were accurate as the next day when management for them.


Support roles taught me to multitask, adapt to changing time-frames, prioritisation, reacting to issues without overreacting, anticipation of issues to avoid a train smash (especially in moments where it felt like I was attempting to herd cats), managing end-users and other teams expectations and competing priorities, communicating technical issues with senior management to name just a few. These were all soft skills. In addition, I learned the system inside out. Many times I learned what not to and why not to design a system a certain way.

So why did I feel the need to write this blog?

Working in a support role has traditionally been the entry point in a career pathway to project work and architecture. It’s a great pathway to take if you want and have the aptitude and desire for project based work. However, a support role is a valuable and important career in itself. And I know quite a few people who take pride in their role and are not interested in project work. Support jobs also have opportunity for growth and promotion (team member -> team leader -> operations manager -> continue).

SAP Support jobs take a special type of person who is able to respond to unplanned issues by providing quality resolutions in a timely manner. Instead of having a go-live party each time they close out a critical issue (that may save $$) they are already onto the next issue at hand.

Interestingly, I have witnessed people from project backgrounds who could not cope in such a high-energy, unplanned work day that is typical for a support role. In one case, a senior manager preferred meetings with a defined agenda sent out in advance, however the issue was time critical and needed an answer on the spot. The project-orientated people were used to planned releases as they moved their change from Development through to Production. Their deliverable was to get to go live (and maybe hang around for a month end). They were not there 6 months or a year later when inefficient design and architecture meant supporting the system was unmanageable.

So, I find it disappointing when I witness a type of snobbery from project members or sense of inadequacy, embarrassment and failure from a support person for doing such an important job. I have observed this in the careers space either by question being asked and some of the advice given.

I hope you give support a chance. And if it’s not for you, at least the respect and appreciation it deserves.



You must be Logged on to comment or reply to a post.
  • Dear Collen:

    Thanks for share this info, 🙂

    I have experienced the same situations as you, I give support to different countries and also in the same language as Spanish is difficult to get the righ information to give the right support.

    Regards Antonio Martinez

    • amazing how language barrier can make a difference. It’s where screen shots and pictures help! My hats off to you – I barely cope with my native language for communication barrier (though most times I am translating nerd).

  • Hi Colleen,

    Thanks for sharing your experiences. Every role is important in our career and especially support role teach us many things..specially user connect.



  • Ah.. finally a blog that speaks in favour of Support projects. This community needed this blog for a long time. Thanks for coming up with this Colleen.

    • I wouldn’t qualify Support as project though. It is BAU. I believe with great IT Service Management knowledge, we can perform better in Support role.

  • Hi Colleen,

    I am so happy to read your blog – as a customer, we often forget who is on the receiving side of messages, and knowing there are people like you is a good reminder.  It’s funny because in a way, I am on the Support side too – as a developer and often a point-of-contact for my users.  I’m lucky in that most of my users already know where the mouse is and can take a screen shot.  I also feel like pumping my fist in the air when I get a call or email with actual information!  A document number, the steps they had taken, what happened then. 
    The next go-live party I go to?  I’ll raise a cup of ginger ale to you 😉 .


    • Haha Susan!

      yes getting excited at receiving the right information is great. In one global support job I had Turkey as one of my markets whilst based in Australia. My shift finished when their day started. Insufficient information meant a 24 hour delay. As a result I became more creative at educating guessing of their issue and creativity in solving their issue instead of sending the call back for rework

      now I’m an advisory/project role. But I Support users will be on my mind to ensure my solution works for them when go live comes.

  • Hi Colleen

    Thanks for a great blog on the joys of support work.   I once had a user who had never dealt with a mouse (she called it a ferret) and had to be taught how to hold and maneuver it 😛 .

    I’ve been doing project implementations followed by support, with rinse & repeat for several years now.  It’s a definite change of mind-set switching from the adrenaline of project timelines to the day to day support, but I like the mix of being able to do both.

    The best implementation consultants are certainly those with understanding of how the solution will be managed on a day to day basis.



  • Although I’ve never worked in support I perfectly understand where you are coming from, since I always thought these people do a very important job (one that I don’t like, but that doesn’t make it less important).

    To explain the snoberry (not to excuse it), at least in my country, many times support is the job SAP people go to when then are tired of the project life and want a better work life balance. In that way, it gives off the impression that it is less demanding, and therefore less “noble”. Not that it makes it right.

    The best implementation consultants are certainly those with understanding of how the solution will be managed on a day to day basis.

    Every project consultant should have to go through one or two months of post go-live to support to learn how their solution is used in the real world. That’s when you learn that what you thought was perfect…. isn’t.

    • there were quite a few angles for this piece. One I considered were the reasons for support work over project but there has been similar blogs on scn before.

      less demanding attitude may come back to the type of environment. some of the perception is more than likely based on salaries too

  • Great article Colleen!

    I personally enjoy Support better. Not because the job is less demanding (which is untrue); it is because I am interested to the business. Whenever possible, I am looking for ideas to improve business processes in the Company. As many implementation projects have its own different focus, some clients still want to use similar business processes as what they had previously in legacy system. This where Support can contribute significant values to the Company; this can start by identifying issues with current process, redesigning the process, managing the testing process, deploying the new process, training the users with new process and getting feedback – this should be a closed-loop process.

    Understanding better IT Service Management is also another way to better contribution. Support team need to safeguard the system in order to ensure that everything is running as usual, and less incidents as possible, and if incidents happen, there is a good control in managing them; hence can be solved in timely and efficient manner.

    I am sure your article gives better clarity on what SAP Support Team do; and many people will benefit from it.

    • Hi Ferdinand

      Thanks for your feedback. As mentioned further up, there were so many angles for support. I have a few other ideas I may develop later and publish. What I did want to achieve in this blog was getting others – like yourself – providing your experiences to show that Support is not a lesser role to Project work. It’s an unfortunate them I see as though there is an attitude that Support roles are part of the progression to project work.

      Process improvement is always important. Companies invest in SAP and the value-add opportunities continue to exist (or may become more visible) post go live of a system. It’s the support people facing the users who are in a good position to see what works and does not.

      So again, thanks for providing some details as to what you enjoy and your view of the world. If you are interested, maybe you got blog out about a Day in the Life of Support and what’s it all about 🙂



  • Awesome and long overdue tribute to the support teams worldwide! 🙂 I felt the same way about the snobbery. It’s interesting how people forget who is picking up pieces and cleaning up the mess after the implementation consultants left for Hawaii to spend their frequent flyer miles.

    Well done!

      • It’s up to companies to increase their investment on internal support, because I’ve seen many companies were maintenance’s only purpose is to give support to users. Whenever the company needs to implement something new, or change a process their bring outside consultants.

        If companies invested in support for tasks related to system improvement and process evolution, even implemementation consultants would see that work in a different view.

  • Dear Collen,

    The Blog surrely provides a better & new  Prespective for those who are starting their career in support ,

    I was SAP enduser for few years and after my certification was looking forward for role into Implementation (for good Exposure & Knowlege ) but had landed up in support role though i was unhappy but now you have given new prespective of looking at things differently as you can get better opportunites &  Challenges which require acitve & alert mind on the go (understanding Endusers Problems & System issue).

    Thank you for this one ,Looking forward for some more interesting experience from your side.


    Jitesh M Patil.

    • Hi Jitesh

      Glad to hear you have taken something away from this article and that you can see areas to develop.

      Project work is great experience as well (I’m on one again now). But Support is also a worthy career path. Also, as companies mature in their ERP implementations they will have less project-only teams. More of their people will be in the Support area who happen to do production-support changes. This still means they go into Development system and make the changes to migrate through.

      I appreciate learning critical analysis and problem solving. What someone communicates is usually a symptom and you need to use your knowledge of the system to find the root cause.



  • Nice blog.

    I have done Support, and I have done Projects.

    Under certain circumstances, Support can be much harder than Project.

    The truth is, there’s a lot of consultants who’s skills/knowledge in SAP isn’t up to par, and trying to deliver a project. They don’t care in what way they do it, all they make sure is to get the outcome client’s wants. But in the end, they use inappropriate tools to create a wrong Design with incorrect data flow, which then affects the whole architecture of how data flow should be. These project normally creates a lot of troubles in long run.

    I would say, the best delivered Projects are not how complicated the solutions are, but more to how to deliver a complicated project using the simplest solutions you can.

    By doing Support, they will realized the importance of creating a project that is easy to support.

    • Hi Vincent

      I have been in support environments where the support team was more experienced than some members of the project delivery. It was a difficult conversation when we escalated to them as level 3 or 4 support to fix it (we would typically explain the issue and tell them how to fix it to avoid rework).

      I always consider support environment in my solutions and simplification is key to that.



      • From experience often the maintenance team is more experienced (well at least older, which doesn’t mean much for me), and that happens because like I said before, maintenance is usually performed by someone who wants a calmer life (even if in the end that is an illusion if the company they are working for is demanding).

        I’ve seen many experienced people getting “eaten alive” but young less experienced consultants because of the “I’ve always done this way” attitude and sometimes the scenario you describe is support trying to impose the “old ways”.

        Not saying it always happens this way, only playing devil’s advocate.

        That said, I’m in a project handoff phase and spent one hour yesterday explaining to a consultant why her code was not up to par. She had designed the code to be used once, by her ….  when I tried to use it …. well….. I had to explain “The time you saved, will now be spent X times by everyone that tries to use your code”. Unlucky for her, the manager (me) was the first one to try and reuse it.

        If she had performed her work with maintenance in mind the customer would have gotten his report in 1 hours time….. this way he is still waiting. This shouldn’t happen, project needs to have maintenance in mind and the best way is having to stick around for a while after it ends.

  • Hi Collen,

    Very Nice blog…

    This will change the mindset of  people who worries about the support issues, as you said support role will increse the understandability of the problem, increase the patience of the consultant, and more over time based result.

    Support issues will make people to learn the new things daily,solving them increases the confidence of the consultant.


    G S Ramanjaneyulu.

  • Hi Colleen,

    Enjoy the blog. It was very easy to understand…even for us end users that are trying to advance their knowledge. 😉


    C. Sandlin

  • Hi Collen

    Thanks for sharing your experience. I liked your screen print explanation, it is impressive 🙂 & I agree that helps to understand quickly.