Jump to content

Status call option


Recommended Posts

Are there plans to have the option of recording an update on a ticket, that would count as a stat for an Agent? 

Or is there a way that we could report on something like this? 

With our previous ITSM, we had the ability to record a "job" being logged in the system that was an update to an existing ticket in the system.  This "job" would count towards the Agent's stats on calls logged vs calls answered.  

At present, Agents are updating the ticket as needed, but then having to log another ticket (likely a self-built quick ticket) to be able to record that they had answered a call.  

 

I'm looking to see if there is a way of preventing the logging of the information twice in the system, which would also help speed up a ticket update for my agents. 

 

Thanks for reading/considering this

Link to comment
Share on other sites

Thanks @Victor, but timesheets isn't what I was looking for, but will take a look anyway, as it might be another way we can looking at stats, in a fashion. 

 

What I'm looking for/wondering if it's possible, is the ability to log a ticket, but when it is selected as a 'status call' it also updates the original ticket with what is typed into the text box, for example.  That way, it would log it as a ticket that has been raised, which we would use for a statistics perspective, to compare the number of tickets raised in Hornbill against the number of phone calls answered by our agents.  

By having this, it would also speed up the time it takes to update an existing job, as we are currently having to search for the exisiting job, add the update comments, and then raise a quick ticket to say "updated job xxxxx" so that it is recorded against a phone call that has been answered.  

 

Does that make more sense? 

Link to comment
Share on other sites

@Emily Patrick umm... sort of... I think...maybe...

So you have a customer/user/contact that phones and analyst raise a request (job) - e.g. request ABC - for the issue/query reported via phone... then, during the request ABC lifetime, whenever the analyst updates the request(*) the analyst also creates another separate request - e.g. request QWE - for the sole purpose of mentioning that request ABC was updated? And then you use the QWE requests for stats?

(*) the request update... is this a specific type of update or...?

Apologies if I have misunderstood the above, I must admit I did not hear of this approach before...

Link to comment
Share on other sites

@Victor, you've pretty much got it, yes.  The update to job ABC could be a user chasing, to see where it is, or what the latest is with it, which would be updated in the job as a work note/comment, so the person with the job is aware the user has chased the job, and then for our stats, we would like QWE to say "user chased".  

When logging a new request (job) it would allow an existing request number to be entered, and then what's entered into the free text box will be added to the work notes/comments of job ABC

Link to comment
Share on other sites

@Emily Patrick right... ok, I understand. I must admit this is a bit unusual for me to see each update on a request being in itself a separate request. May I ask what is behind the decision to work like this? Is is solely reporting/stats, something else as well? I am just thinking that separate requests (for what constitutes a Hornbill request) is somewhat overkill for this particular purpose and trying to see if we don have alternatives that are more suitable for Hornbill and to meet your needs...

Link to comment
Share on other sites

@Victor it was how we recorded updates in tickets in our old ITSM, and that was developed by people within our department.  

If there is another way that we can do this, where we can also report on it for stats purposes, I'm open to ideas/suggestions and can then discuss with those within our organisation on how we can go about implementing something to capture this information. 

Link to comment
Share on other sites

@Emily Patrick putting the stats on the side for a bit, do you find the request timeline not sufficient for the purpose of tracking updates on requests? You say that your analysts have troubles or is time consuming searching for requests to apply a certain update? How do they do this? With a reference at hand, there are ways to quick access the request and simply apply an update there... (imo)

As for stats, what exactly are you tracking on a request? How would a report look for this stat?

Link to comment
Share on other sites

  • 1 month later...

Hi @Victor

As I'm in the process of creating a quick ticket for the stats side of updating a job with an update/chaser, I had the idea, that in the Dynamic Drop down selection box in the PCF design, could there be an option to search for requests under the 'Data Provider' section? As per the below screenshot? 

image.thumb.png.d748f50633f4d0eefd3c4811bf179a2e.png

 

This could then look up a job number when inserted, and if possible, somehow, add an entry to the timeline of the entered job, thus putting an update in the ticket for the end analyst, while also ensuring that a job is logged which can be reported on, to show that a user has answered a call and logged it in the system, meaning they are able to hit the target that has been set for them.  

 

It's just an idea I had as I'm creating a form for us to use. 

Link to comment
Share on other sites

It's not completely clear what you're trying to achieve through this form?

 

If a Customer calls in to chase a Request, I would expect them to have the Request Reference, otherwise how would you (or they) know what was being chased?

Marking the timeline of the Request being chased is easy enough - if you're raising an additional tracking Request then the Customer gives the Reference, you put it in a Custom Field, and use that in the tracking Requests BPM to update the related Request (and probably link it as well.)
Alternatively, you could press CTRL+SHFT+F and type the original Request Reference into the popup, which opens the original Request and just directly update the Timeline - this will send a notification to the Owner and they'll know it's been chased without the need for a second Request.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...