Assistance needed with Decision logic module

[gol4]

All of our service departments are grouped into 1 division and under the vision of our VP a service center was formed because customers should not have to know which department handled their request. Customers should see us as 1 department. All requests are routed thru the Service Center.
The service request is set up so customers give their facility-location and contact information and in another field make their request. The dispatchers look at the text and select the department for routing.The request is then automatically sent to the proper pagers-staff.

Any logical human with very little experience can look at a request and figure out the appropriate department.
Examples of various requests and department it would be routed to:
need trash emptied in room – Housekeeping
sink plugged in restroom- Maintenance
need lunch tray to 704-Food Service
Need pillows to 804-Linen
My task-challenge now is to further automate this process.
I need to parse the text and provide the department for routing

I attacked this by creating a keywordtbl that has the fields
(keyword, Department, rank)
Clean,housekeeping,1
Broke,maintenance,1
Lunch,Food Service,1
Table now contains a few hundred of these keywords

Then using instr and summing on the rank
SELECT KeyWordTbl.Department,sum(rank)as tot FROM KeyWordTbl where instr( [calldescription] ,keyword) > 0 group by department.
The one with the highest sum of keywords seemed the logical choice for routing.

In running this logic against previous requests, the best I can get is about 70% accuracy.
The problem I run into on about 30% of the records(example)
clean up broken glass in utility room
glass broken on door in clean utility room
would score the same for maintenance and housekeeping.
Obviously this logic is not good enough to automate the process.

What algorithms could I research that would be appropriate for this type of decision making.
I know the easiest solution would be for the customer to select the department but that is not an option .(See VP vision).
Any Suggestions would be appreciated.

 

[Mike555]

To your credit you've obviously done a considerable amount of work here. I think that you're reaching the []bhow good is the application / how much do I train my users to type the right stuff[/b] threshold. Why not train your users to make sure that they understand how they should type stuff into the system in order to achieve maximum accuracy? It may take them a while to learn the best way to do it, but it wouldn't be asking too much.

 

[gol4]

Mike,
Thanks for your comments.
I will certainly look at the training aspect as well but since our dispatchers have been able to tell which department to send it to based on the data entered I still have to believe there is some programmable logic I am just not sharp enough to catch onto here.

 

[GingerR]

I don't think there will be anything any more programmatic than what you are already doing. I don't know how you could "mine" free-form text entries by the users and make them group into sensible categories on their own.

Maybe the user interface could be restructured to sort of walk them thru choices in a drop-down box or option box based on your experience/data of what already happens, and these choices would map behind-the-scenes to a dept:

Something needs to be cleaned
Something needs to be fixed
I need linens (pillows, towels, bedding)
Empty my trash
I don't see it on the list

Then after that, maybe a text box for additional info if appropriate (what is broken, what room should linens be brought to, etc), and/or additional drop-down or check boxes for like linens which shows the different linens. For the "I don't see it on the lists", there'd be an additional text box for them to put in what they want. You could routinely check the "I don't see its" and if there are enough of one kind, make it a new "standard" on the list. At least this would route a lot of your stuff without the need of a dispatcher....and the users really wouldn't be picking a dept, they'd just be describing their issue in a different way.

Sorry I don't have anything cooler than that to offer....

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html

 

[MichaelRed]

In a general parseing schema, you are not going to be scoring all that much better. I would tweak the keywork rankings by their placement in the statement. This would at least greatly decrease the scoring ties and -with somr accumulated history of the scoring hits you could at least see wheather the schema changed the process. Note that even a negative change could easily provide the necessary resource to correct it. My knee jerk reaction would be that the sooner the keyword appeared the more important is is, thus the lower the Instr value the higher the importance.

Another common technique to use in parseing for content is the relationship betwee keyword placement, so related keywords close together are more important than the same ones further apart, e.g. Broken Glass would be more important than some stuff was broken and I need a glass of water. So another avenue would be to set up keyword relationships so you get the more important parts first (or higher on the scale)




MichaelRed

 

[jsteph]

gol4,
I will second GingerR's response. But first, how is this request being entered? Via a web browser? An Access App?

Either way, most web-support pages, for example, do it as GingerR had said--they walk you through with some simple qualifying options. It's not difficult, it is typically presented with the text 'To help us serve you more quickly, please select the general area of your question/concern/problem/need, etc.'

I know this goes against the 'vp vision', but there are times when you've got to put on your analyst hat and let it be known (to the vp) that in your professional opinion, the time involved in creating such a monster, the support complexity, the maintenance headaches, and the fact that the best you can hope for is significantly less than 100% accuracy--all must be weighed against the simple notion of having the customer help out a bit.

You've got spelling issues that will occur, the obvious ambiguity of some of the examples shown, plus the csr's are going to have to can through them all anyway, since the only way you can know your current 70% number is to either have the csr's scan each one--or wait for the time-cosuming process of the request coming back from a wrongly chosen departement.

It's just my opinion, but I just think that, while it's a noble challenge and maybe even fun and interesting, I think that job 1 should be the efficiency of the system as a whole, not just trying to micromanage a single logic engine that will be expensive (in terms of dev. time) and can never hope to be truly perfect.
--Jim

 

[gol4]

Thanks everyone for your responses
GingerR and jsteph changing the user interface is certainly my backup plan if I am unable to get some accuracy out of this parsing plan. GingerR I do think packaging it as asking for the department with out really asking for the department is a cool idea. Did you spend some time in SALES?
The development costs are not the issue I waste more time a week on perusing tek-tips then what I,ve got into this section. I am certain the accuracy will wind up be the death of this plan.

MichaelRed. Your response has certainly come the closest to what I asked for. I will spend some time on testing out that theory today.

 

[GingerR]

I've never been in sales, just a customer. It's not outlandish and people are used to that kind of thing. Even here at work we go to "PC Self Help" on our intranet to write a ticket, you don't even talk to a person any more. Make some selections and hit the button. They only call if they have to (or if I pick that I want them to call me). With a little work from me (the customer), the Help Center people can get their job done easier. I can see the queue and where my ticket is and everything. groovy.....

Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244. Basics at

http://r937.com/relational.html