Call Center Database in Access (1 Viewer)

James.Leon

New member
Local time
Yesterday, 21:45
Joined
May 22, 2016
Messages
5
Good afternoon All,

I hope you are all having a great weekend.

I recently was assigned the task of creating s Call Center Database in MS Access. I'm a total noob to MS Access. I've purchased a couple of books and have researched many website for templates on how to create a Call Center Database and have been unsuccessful.

Any of your guys's input would be greatly appreciated.

Thank you in advance,

James Leon
 

James.Leon

New member
Local time
Yesterday, 21:45
Joined
May 22, 2016
Messages
5
Thank you Gina for the information. Have a great day and weekend.
 

GinaWhipp

AWF VIP
Local time
Today, 00:45
Joined
Jun 21, 2011
Messages
5,901
You're welcome... Now, when you get your Tables built, post back so we can have a look!
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 23:45
Joined
Feb 28, 2001
Messages
27,001
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.

2. 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.
 

stopher

AWF VIP
Local time
Today, 04:45
Joined
Feb 1, 2006
Messages
2,396
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. With a call centre database it is very easy to get carried away. If you are going to going to capture complaint reason for example, you may come up with say a dozen complaints categories then you decide to add a text box to capture some details. This may be fine but be mindful that call centre agents are typically time concious and whilst a call may take say 5 mins for example but you add on another minute while the agent completes some details they weren't doing previously, that's a 20% increase in resource time. Call centre analysis is brutal in this way. So really understand what you really need up front. Start simple and build. Don't change every week, call teams get frustrated if you keep changing regularly. At a very simple level you could record just the contact details. At the other end of the scale you could record the entire mechanics and details of the call, who, what, why, where, when ...

Once you've got the above nailed (see Gina's posts) then you can think about the interface. The interface for a call centre really does have to be stream lined. The agent is often thinking on their feet so they don't won't to be thinking hard about how to deal with the computer and having to navigate a long list of options. For call centre interfaces, it is often the case where the interface follows the course of the call. For example, the first "page" (think form or dialogue box in Access) might be the type of call the customer is making. So if the call is about a complaint, then the agent clicks complaint and the next page (form) is a complaint form etc. The point is, the agent does not navigate through menus but instead kind of follows a questionaire trail according to the caller responses and the course the call takes. A couple of reasons for this. The first is you can record the call journey through the pages chosen. The second is you can provide the agent with "scripting" i.e. prompting to help them know what to ask the caller next which means they don't miss anything relevent to the particular call. Such a system will often provide the relevant links at the relevant points e.g. a product FAQ link. This is quite a different philosophy than the agent having to navigate menus or Windows to a relevent screen. The nature of this questionnaire/script approach means rather than designing loads of forms for every possible combination of response, forms (or dialogue boxes) will be dynamic which is a little different to the static form/menu approach.

hth
Chris
 
Last edited:

James.Leon

New member
Local time
Yesterday, 21:45
Joined
May 22, 2016
Messages
5
Thank you all so much for the feedback. I'm analyzing the information that has been provided.
 

Users who are viewing this thread

Top Bottom