Another issue that you need to consider when designing a call-center database is that you need IMMEDIATELY to know expected call volume and the expectations of the persons who manage the call center as to what they see. Some folks can design a database 'shooting from the hip' (as we say in the USA) but your accuracy will about what you would expect if you don't take careful aim first. And that 'careful aim' requires a LOT of digging to get a detailed requirements list. For a problem as complex as a call-center's logging system, you will need to assure that you don't do things in the wrong order. I will offer you two Old Programmer's Rules that might help you here: 1. If you can't do it on paper, you can't do it in Access. Meaning: If you cannot decide what you want to do, trying to do it Access will fail miserably because Access will only do what you tell it. To download, please go to http://www.sobolsoft.com/customercalltracking/. Access can't tell you anything you didn't tell it first. Meaning: If you want to see reports on X, Y, or Z for your call center, your database has to TRACK items X, Y, or Z, or has to know the formula to derive X, Y and Z from what it already has on-board. This, of course, feeds back to rule #1 above, but is so important as to be worth separate comments. Following on from The_Doc_Man, a call centre database is a tricky one to pin down. If you take the example of an ordering database, these are normally quite easy to design because there is a clearly define paper system and the database is put in place to replicate. With a call centre it is often a step into in unknown. The agents are usually already dealing with the business so to speak. The database of a call centre is often to provide some value added service rather than the call service which is likely to already be in place. This could be capturing contacts to build a contact database or to provide a better customer interaction (because you can readily pull history). It could be to understand the types of calls being received e.g. Help/support, sales, complaint each of which could be broken down into sub categories in order to understand where investment is required. It could be to monitor agent performance. It could be to monitor the caller satisfaction/outcome. It could be to monitor/improve the call journey. It could be to support the agent in the enactment of the call i.e. Prompt with knowledge The point is, going back the The_Doc_Man's point, you really need to understand your mission here and be clear about what the database needs to record and delivery. Someone who says they want a call centre database may not really understand what they are asking for.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
April 2018
Categories |