We run a periodic survey to know what our customers – internal departments as users of various SAP Solutions, think of support services provided by our CoE team to them. The questionnaire is sent to all end-users. Some reply, some could not. The results give us general understanding of which areas of our services need improvement and thus such survey has its own value. However, as we couldn’t determine the exact pain-points with such approach, I was thinking of and had suggested my counterparts in IT of implementing “Services-specific” feedback i.e. seeking beneficiaries’ feedback after completing a project or implementing a CR.
The idea was well-received and we had many suggestions on how it could be implemented. To ensure our thoughts are aligned with others who have implemented similar process, I sought help from fellow SAP community (which is really a great place to get such help) at
Specific OR General Feedback? The response was great and helped a lot in restating the value, in meetings with my team, of having such mechanism in place (Thanks
rashid.javed and
zubair.naseer3 for your kind & prompt response at Q&A forum). We started evaluating the solution & services provided by Technical team to internal business for one of the projects – summary of which I have described earlier at
Migration from Microsoft to SAP CRM – managing change. Here I’m sharing the key learnings from the first round of such interview.
Whom to ask?
Since its service-specific feedback session, the beneficiary of the service is the right person for such discussion. In some cases, the requestor of service may not be the actual beneficiary, hence, knowing whom to talk is important. Once figured-out, the next challenge is to take them into your confidence as not everyone will be willing to provide frank feedback.
What to talk?
I found talking about following points very useful:
1. Comparison: Comparing existing solution & associated services with new reveals very good insights on expectations from new system and the new support team.
2. Major benefit: Talking about the major benefit(s) of new system over old helps in convincing the end user(s) of preferring it instead of looking at minor benefits offered by previous solution.
3. Project Schedule: Mentioning about project schedule, especially if it was within promised timeframe, could gain user’s confidence on promised timely support when needed.
4. Team Support: Asking about the initial support which leaves very sound impression, good / bad, could guide in implementing or improving the support model in place.
5. Issues Resolution: Inquiring about the issues and timely resolution builds user confidence on service provider’s commitment on keeping customer on priority.
6. Requirements: Promising on addressing the new requirements / design change requests in timely manner, after the new solution is live, helps in easy acceptance & adoption of new solution.
Keeping the discussion around the above points depends on the project type; I found the above enough for initial meeting and intend to build on these points in future sessions.
When to discuss?
Well, it depends on the situation. The ideal time for initial meeting, in my opinion, is a week after implementation, basically after users have used the system somehow. However, it shouldn’t be limited to one / two meetings only but at least until users have adopted the system to a level where they are confident in using it independently.
Do you have similar / better experience / thoughts to share?
I’ve scheduled such sessions with other end-users in coming weeks and hope to have additional feedback which I’d be very happy to share. However, as it’s a process which could be improved over time, if you have some suggestions, please do share.
