Status call option

[Emily Patrick]

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

[Victor]

Not sure I fully understood what you need, but perhaps you are looking for some for of timesheets to record the time spent by analysts updating a request and other activities performed? If yes, then: https://wiki.hornbill.com/index.php?title=Timesheet_Manager

 

[Emily Patrick]

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? 

[Victor]

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

[Emily Patrick]

@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

[Victor]

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

[Emily Patrick]

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

[Victor]

@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?

[Emily Patrick]

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? 

 

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. 

[Steve Giller]

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.