I saw this post and couldn't help but respond... :-)

I've found in the past that "response times" can be a very contentious issue. But my take on this is that it must be from the customer's perspective of how the question is being progressed, so I say the customer see's the "first response" as the first steps towards resolution (a suggestion, request for more information, etc) and not just confirmation that the call has been logged and has an associated reference.

Too often auto-responders are used as the measure of whether first response SLA's have been met; but from a service perspective, the customer hasn't received anything yet.

Any thoughts, anyone ? :-)

I would agree with Russ. We have used Acknowledge in the past but it was with various success. The way we have the templates set up it can be easier to use another another action type to update the client (such as request for further information) but then you do not get the right date/time stamp as per acknowledge. You then end up either using the ack option and add the other detail to that action such as email templates etc or you end up doing both.
For this reason we went away from using this.

My vote also would be the first action be it a status change or notes update. The only thing I would exclude is the reassigning of a job. When I reassign I move the ownership but this does not mean that anything has happened or the customer has been updated.

Hi Russ and Timo, thanks for your input. This is good feedback.

Sounds like both of these preferred measures of response time can be pinpointed by reporting on the first time is placed into a specific job status.

A best-practice that we suggest with HelpMaster (or any helpdesk system) is to use an "us and them" naming convention for job status. To use a tennis analogy, when the ball (job) is in the clients' court, the job status reflects something like "Client : Awaiting response". When they do respond, the job status changes to "Staff : Awaiting response" or similar.

So what I'm getting from your feedback is that a good definition of response is when the client is actually contacted by someone at the helpdesk / service desk etc. In the example above, it would be the first time the job status is changed to a job status like "Client : Awaiting response" or similar.

Perhaps a future HelpMaster improvement / feature could be to mark certain job statuses as being the trigger for a response?

Another other ideas?
Rod

p.s. Russ - great to hear from you again.

We picked up the "us and them" approach from this website a while ago and have been using it ever since. One of those simple but effective ideas.

As to the question though. When we log the job is is set to "0. Open Issue" and so in other words nothing has happened on it yet. The next step could be one of two mainly.
"AB: Work in Progress" - we have started to work on it
"Client: Awaiting Customer Response" - we have requested more information or we could have provided the solution and just awaiting confirmation. in this was then it incorporates the WIP status and the ACR status in one.

so a status change would be good to have as the trigger but it may not be any specific status listing.

Hope this helps

I would agree with "the two state" persepctive... we're either doing something or waiting for something... although, in our present circumstances, we have a 3rd party, the app. vendor (to show as a location, not so much a status change), when coding issues need to go "back to base." (and we need to account for 3rd party SLA's)

But to continue the tennis analogy, we occasionally have to refer to Hawk Eye when someone shouts "Out !!" (Maybe HMP could throw out some chalk dust... :-)

We would entirely agree with Rod above, that a response is "when the client is actually contacted by someone..."

Triggers driven by status is a great idea. And when linked to age, or time progress against SLA for that priority, this provides the customer with assurances that work is happening, without them needing to chase... which means less interruptions, less escalations... and so we all lived happily ever after... :-)

Just had another thought. Would it be possible to set the SLA based on the priority. Currently when we log jobs we assign a priority ( / impact state).
It would also be good if we could set the associated SLA again the system code. So if then I select a P3 then the system would already know (and notify) that it needs to be done within 2 days, if it is a P4 then it would give it 5 days.

Currently the only way I can see i can do this is by setting the Time Option "set the 'To be completed by' date to be in ..." within the job template. This is ok but not great as then I have to set up a job template for each priority which in the end is counter productive.

Is it possible?

Hi Timo,

If you need to set the "To be completely by" date in the job, you can use the Priority Manager to do it for you. See http://www.helpmasterpro....n-Board/aft/292.aspx

Once this date has been set, you can then create another Priority Manager profile to send the SLA notification emails and breach warning etc. See http://www.helpmasterpro....on-Board/aft/39.aspx

We are also considering a major enhancement to the Priority / SLA / To be complete by feature for an upcoming version of HelpMaster that will be largely driven by the priority of the job.

Hope this helps,
Rod