My last post started talking about the questions to ask when you blueprinting the SAP Service Management / Customer Service modules. This next installment is the SAP SM Blueprinting questions I ask regarding the call center. If you want more details, check out my post about Blueprinting Questions – Master Data.
Are you currently using call center tickets/notifications?
This question is how you can initially determine exactly what your client needs to run the call center. Some clients don’t currently use notifications or any sort of help desk tickets, and other clients can’t live without them. If they are currently using notifications, you follow up with some of these additional questions.
- Do you use multiple notification types?
- Some clients want the distinction between return merchandise authorizations, simple call center calls.
- It’s important to understand what is different between each type of notification. It might be possible to consolidate notification types, and report in different method.
How many calls are you tracking in the course of a day/week/month? How many people are taking these calls?
This question will help you to gauge exactly how much time a call center representative can devote to entering a help desk ticket. If you receive a 10,000 calls in a month, and it’s spread between 4 people, the call center won’t have the time to capture every detail of every call in a ticket. However, if it’s a well manned call center, it might be feasible to turn every call into a notification that may be closed when the call is ended, or may required follow on actions.
What information do you capture during a call?
This is the biggest piece of your work for the call center. Based on this information, you can design your first pass of the notification. Including what screens and what fields should be on the first tab, and at the top of the page. Remember, you can capture as much information in the notification as you want, but there is a trade off between time to enter the data and how you use that data. Be sure to stress that you should only capture what you will use, or your just throwing away hours on data entry.
Do you use tasks/objects/etc. in your notifications?
This is question that determines just how functionality you will incorporate into the notification. Implementing tasks/objects/activities etc. gives you the option to incorporate workflow, and assign tasks to individuals. You want to be careful with this, since this functionality can add a lot of overhead to maintaining your notifications.
Do you generate repair sales orders directly from the notification?
If you do repair processing, or even straight returns, you need to generate repair sales orders or return sales orders. This is standard functionality in SAP, but remember to be aware that only limited data from the notification is passed to the sales order (unless you enhance SAP). For example, there isn’t an out of the box action button to generate a return order.
What follow on activities are needed from the call center?
Notifications in SAP can spawn other activities that need to happen, or simple things that need to be logged, like a phone call to the customer, or add an entry to the solution database. It’s important to understand what your customer really needs. Most customer initially think they want a lot of these things. Remember, to keep expectations in check. While all of this and more come standard in SAP, it’s important not to overload your call center team just because something sounds cool.
- Log Phone Calls
- Create Internal Note
- Quality Notifications
- Send Confirmation of Receipt
- Solution Database
- Send Final Notice
- Other Actions?
Do you generate service orders directly from the notification?
Remember, when you start this discussion that there is a difference between the repair process and simply generating a service order directly from the notification. Typically, when a service order is generated directly from the notification it is either for quoting or perhaps for on-site/field service. For in house repairs, best practice is to use the repair sales order/process, which is often generated from the notification by the action box. Often this question is either a part of or leads to a process discussion. How do you want to generate your work orders that are not in-house repairs. This will vary from client to client, but I’ll always recommend that you keep your processes similar whenever possible (so make your field service orders work similar to your in-house repairs).
Do you have any workflow or customer programs designed around the notification?
This question often ties into the use of tasks/objects etc. This question covers you in case you need to worry about interfaces that create/change notifications in the system, or any emails/workflow that are required during the processing of the notifications.
Do you currently track any metrics around the notifications?
This is always a tough question to tackle during blueprinting, but it’s better to gather the requirements now. In short, what are the company metrics your call center is measured on. Sometimes these are corporation wide, other times they vary from division to division. Either way, you’ll want to find out how the call center is measured, and be sure to include a method in your notification to capture that data. Most likely, you will need a custom report to deliver this information, but nevertheless, find out early. Here’s some common metrics I’ve encountered.
- number completed
- Amount of time open
- Number of open tasks
- Etc
Do you have any on-line/web based notification entry systems for your customers or suppliers?
Finally, does your customer have any web interfaces or tools that allow your customers to by-pass the call center by registering their own products or creating their own RMA’s. This is a great cost savings, but requires significant programming to accomplish.
Alright, that’s what I have for this round. I’ll be back soon to continue this blueprinting discussion. Again, please chime in with anything else in this area that I may have missed.
Thanks,
Mike
www.paperstreetenterprises.com
Mike