Call ticket application

[Rob Martire]

We are looking at implementing the Call ticket application as the first step when the user calls into the help desk instead of creating an incident. One of the concerns is that the call ticket is not extended from the Task table. This will prevent us from having the list of call records in My Work queue which is based on the Task Table. We are also not able to create SLA for the call records because as per the wiki you can only create the   SLA on the task table or tables extended from the task.

I would like to see how other organizations are using the application.

Thanks

[ChrisPope]

Robert,

The New Call application is designed to work as a scratchpad or capture point to gather information through questioning and then launch into the appropriate ticket type, such as an Incident, Request or Change and such like. Too often Incident is used as a dumping ground, mis-classifying, copying and pasting one ticket to another and then trying to find the right home for it. Calls shouldnt have SLAs, the work that they turn into or drive have the SLAs attached to them. Else you are really trying to measure handle time on the phone and there are already ways to do that. The Left-Nav option for 'My Calls' could easily be re-ordered to be part of the Service Desk Agents menu, next to My Work as an example.

There are also various updates on Share available that have been built that extend the functionality further to add more intelligence and relevance to the Call record, by using Related Lists and matching on the user, email, location, CI and such like....it also brings in the Open Incidents or Requests for the same caller. Use case being they already called and are escalating or chasing, thats not an incident but you want to record the work and capture it.

Hope this makes sense,

Chris

[jonathonbarton]

Robert,

I'll add this to what Chris Pope wrote...
Calls are not Tasks, and the're definitely not Work - they're almost exclusively an intake function, and nothing more.

Quite often, a Service Desk Agent will pick up the phone and go through some sort of inquiry (Who Are You?), followed by some Triage (What Do You Want?). The Agent needs someplace to record this information *BEFORE* making the decision on whether the Call is describing an Incident (My keyboard is broken), or is a Service Request (I want a wireless keyboard), is Neither (When can I expect my Wireless Keyboard to arrive?), or is None of the Above (Sorry, wrong number...*click*). One of the issues that the Agents were most vocal about after my first deployment was the fact that they Agents would feel like they had to ask the caller who they were, then get the Triage, decide whether it's an Incident or a Service Request, and then...ask the caller who they were again! Very repetitive, and very frustrating for both the Agent and the Caller (since it looked like the Agent didn't have it together...)

By default, when a Call is transferred to an Incident, an Incident is opened, the Incident Number is recorded in the Call Record, and (this is the important part...) The Call is CLOSED, having served its useful purpose 99.9% of the time. Very rarely (the 0.1%), the Agent will hold the Call open for more information, and the Call can be seen in the various Call-related Left-Nav options, but the disposition of every call should be swift, and I haven't seen a single instance where my immediate reaction to seeing a call that was being held open wasn't "WHYYYYY?"

In an advanced application of the Calls module, I worked with the client's Shoretel Administrator to get the Shoretel Soft Phone application to pass a URL with the Caller ID data to the New Call module, so that each new phone call to the Agent would pop up a New Call tab, prepopulated (wherever possible) with the user's data (with Related Records for Open Incidents and Open Requests and Assigned CIs), which was queried using the user's Caller ID number against the sys_user table. Each Call could be 'disposed' with one of the following statuses:

Converted to Incident
Converted to Service Request
Incident Inquiry
SR Inquiry

General Inquiry
Hang Up
Wrong Number

Hope that helps!

[karstenvan · Accepted solution]

I think the key decision point on using the Call plugin vs. doing a custom Call-type table (that extends task), is how you want to use the table in your work process.

If you are just using it to record notes from a phone call, then based on that real-time info create an incident, request, etc... then I think the Call plugin will work for you.

However, if you are wanting a pre-incident/request landing zone that you will use for initial review/triage (ie. for incoming email requests), then I would do this on a table that extends task.

The key logic for using option 2 is that you have incoming work items (ie. email) coming into a queue that requires someone to process them at some point in the future... therefore they are tasks and should have due dates, slas, and other task-type fields applied to them for proper management and performance measurement.

Personally, I've usually wound up using the approach that extends the task table in most situations.   The only situation I would likely use the new_call plugin approach would be a phone queue-only call center.

[Kalaiarasan Pus]

We have a custom Call application extended from Task just for few of the reasons presented by you.

But, the gentlemen above are also right in their approach.