Where did Waiting for Customer go?

[badcaptain]

One of the best features was the waiting for customer flag. Is there a plan to bring this back or is there something that is similar in this new version?

In general, I like the new look and feel of the new version, but feel that some of the key help desk features are gone. Understand it's cleaner code, hopefully some module documentation will surface soon :)

[jstanden]

Hey there!

"Waiting for Customer" in Cerb4 is (as a search):
Last Action = Worker Reply
Closed = false

In the interface you'll see something like "Outgoing reply from badcaptain" in the ticket list, and the ticket won't be closed.

So "Waiting for Customer" is implied, but it works exactly the same way. On reply it will flip to "Incoming reply from customer@host" (or "Incoming reply for badcaptain" if the ticket is assigned).

That gives people more contextual and useful information from the lists without adding superfluous properties. :)

[bbillings]

Well, it isn't really superfluous, the 4.x setup makes the assumption that an agent response means the ball is no longer in the agent's court. If I get a new ticket in, I may respond back initially with a "Thanks Joe Customer, we're looking into this and it may take a few days" type of E-Mail, something more personal than the auto-response. That scenario means it shows up as "waiting for customer", even though it really isn't and will fall of the group's radar.

I suppose a custom field could do a similar function, although it was nice to have the flag automatically clear on customer response.

[peter_mcc]

Hey there!

"Waiting for Customer" in Cerb4 is (as a search):
Last Action = Worker Reply
Closed = false

In the interface you'll see something like "Outgoing reply from badcaptain" in the ticket list, and the ticket won't be closed.

So "Waiting for Customer" is implied, but it works exactly the same way. On reply it will flip to "Incoming reply from customer@host" (or "Incoming reply for badcaptain" if the ticket is assigned).

I don't think it works the same in V4 as it does in v3.5 at all.

When replying to a customer in 3.5 I would tick the "waiting on customer" box and set a "due" date. I then have a view set up in my dashbox that shows all the tickets waiting on customer replies and when they are due. If I'm going to be out of the office for a few days I can easily see which tickets will become due and chase them up before I go.

In 3.5 there is a difference between tickets where I've replied but the next action is for me and ones where the next action is for the customer (eg I reply to say "I'm looking into it" vs "can you please try this").

I'm not sure how it's all meant to work with v4.

When playing with the 4.0 demo I ticked the "this conversation is completed for now" box and set a due date of +10 minutes. The ticket then disappears from most views as seems to have been closed. I'm not entirely sure how it's meant to work but this seems rather confusing to me!

Questions:
- If I find the ticket (using search with no criteria - so it shows the closed tickets) there is no indication I can see of when it should be "reopened". Is that just because the standard views don't display the "due" column?
- I can't work out how to show, in a workspace, all the tickets that are waiting for the customer to reply. Is this possible? This is related to the quote above. I don't want to group all the ones where I replied last together (see my comment above) as some are waiting on me and some on the customer.
- If I tick "this conversation is completed for now" then I don't get to set the "next action" text in the reply form - however the last used value is displayed in the "search results" (and probably elsewhere). Yes, I know I can go to properties and change it but that's an extra step.

Is there some guide to how it works that I've missed?


As an aside, which scheduled task "reopens" these tickets? The demo was confusing because I was setting due dates and nothing was happening (true - they were 5 mins into the future but even after 1hr nothing had happened!). I adjusted the scheduler for all the tasks and ran them all manually then things started making more sense - the previously closed tickets that were waiting on the customer were reopened


Peter

[jstanden]

Hey there!

If I find the ticket (using search with no criteria - so it shows the closed tickets) there is no indication I can see of when it should be "reopened". Is that just because the standard views don't display the "due" column?

Yeah, "due" is a misnomer, but that's currently the column controlling when a closed ticket automatically reopens without the customer replying. If the customer replies earlier it will become visible no matter what.

I can't work out how to show, in a workspace, all the tickets that are waiting for the customer to reply. Is this possible? This is related to the quote above. I don't want to group all the ones where I replied last together (see my comment above) as some are waiting on me and some on the customer.

We just finished up and committed the custom fields feature. They seamlessly integrate into Display Ticket, Searches, Worklists, Support Center, etc. This is really the best way to fine-tune your workflow.

The upcoming 'tasks' system will also be a much cleaner concept for assigning tasks, workers and due dates and linking them to specific tickets or clients.

Cerb4's entire philosophy is if you can't act on a ticket you should get it out of the way, instead of having it be a constant obstacle (with a mental reminder) on every list or open ticket total. That's why the 'reopen' feature closes the ticket.

It's easier to get more done when you're working toward zero open issues, and you temporarily archive things you can't possibly do anything about in the meantime.

I agree with your desire to know the difference between what you replied to, and what is waiting on you. Tasks really make a lot more sense for that requirement than tickets do. You'd just end up with a short worklist of tasks (instead of tickets) that you could sort by date. It wouldn't matter if they linked to open or closed tickets when they were due, since you'd be completing/delaying tasks independent of the ticket's properties (the ticket becomes a reference for the task).

As an aside, which scheduled task "reopens" these tickets?

The "Heartbeat" job handles that.

[jstanden]

I suppose a custom field could do a similar function, although it was nice to have the flag automatically clear on customer response.

True enough. However, that would be incredibly simple with our event/plugin system.

I'll see if we can implement something like 'Waiting for Reply' as a plugin, so those of you who want it can use it -- and I'll be happy because I won't have to pollute core with another manually juggled ticket property. ;)

In our little helpdesk world, basically every ticket is waiting for reply all the time. Nothing is permanently closed until the customer is happy. The "reopen on" feature just lets us ping the customer again.

[Shaun]

I would like to see this feature added back also. Just because we responded to a ticket doesnt always mean that the ticket is awaiting a response from the customer. A custom field is annoying to use. Also if you do implement this as a pluggin or add it to the system it would be nice if there was a option to set this field to checked/unchecked by default. The old version didnt have this feature and we hacked the code to make it always checked because 90% of the time we are awaiting a response from the customer.

One thing that worries us about Cerberus is that every time you guys come out with a new version it's like we changed help desk software company's. We are having to relearn the software, features that where once there are gone, and we basically have to rethink the way we do things.

[jstanden]

I would like to see this feature added back also.Noted!

One thing that worries us about Cerberus is that every time you guys come out with a new version it's like we changed help desk software company's.We're always going to work toward the best answers by aggregating feedback from thousands of helpdesk environments -- even if the better solutions are discontinuous with the old ways of doing things. There are a hundred other helpdesk projects out there which specialize in not evolving. We prefer to learn from past mistakes and adopt better ideas earlier. ;)

The 3.x versions had so many consistency problems, and were difficult to maintain, specifically because we avoided making the radical changes that were badly needed.

With 4.0 we had the ability to rethink every concept with the benefit of 6 years and ~18000 installations of hindsight.

What you mentioned is really the best way to go about it: consider 4.0 as an entirely different application than 3.x.

The 'Waiting for Reply' concept is interesting because of all the different ways people use Cerberus. At the same time, some people impulsively try to use Cerb4 exactly like Cerb3 without stopping to understand the benefits/rationale of the changes. That mindset is not healthy for the community.

All that aside, we're listening. We're happy to have you here, and I'll gladly discuss any topic you like.

[peter_mcc]

Noted!
So... any idea when we'll see something? It's one of the major issues thats causing me to wait before upgrading!

peter

[jstanden]

I created a roadmap task here:
http://www.wgmdev.com/jira/browse/CHD-428

It's high priority and assigned to me. I'll try to get to it Weds afternoon (Pacific time).

[jstanden]

This is in Subversion now. ;)

[Fido_One]

Let me first say that I think Cerberus is one of the best Trouble-ticket systems out there, but I share the exact same worry as was mentioned in this thread earlier and I'm rather paranoid it'll sink the Cerberus ship in our establishment.

I just updated to build 500 on Cerb4, which I've just started using for one or two small services in our institution. I want to roll it out to the 3 major support service areas at the college but the process of upgrading to the most recent build (which I had to do due to the CC bug that was fixed) is making me a bit weary.

A lot of the new changes in the past month made *me* scratch my head until trolling through the forums here. The 'ticket moves to waiting' won't work for our establishment right now - I see the point, but staff would not, and that is where the issue comes with updating in general. (Sorry if this response is in the wrong thread, but the 'waiting for customer' issue is what brought the issue up).


Quote:
One thing that worries us about Cerberus is that every time you guys come out with a new version it's like we changed help desk software company's.


We're always going to work toward the best answers by aggregating feedback from thousands of helpdesk environments -- even if the better solutions are discontinuous with the old ways of doing things. There are a hundred other helpdesk projects out there which specialize in not evolving. We prefer to learn from past mistakes and adopt better ideas earlier. ;)



I appreciate that response and on one hand do not want to hinder your methodology... But it basically means I need to set up a staging server to evaluate the rather frequent updates, which I simply don't have the resources or time to do. And it makes it considerably difficult if I just want a bug resolved, not new functionality.

I know that Cerberus 4 is a hell of a lot better than our existing trouble ticket system, but even if it came with a cherry sundae and a free car I'd still have quite the battle to fight to get it rolled into the areas which I want it used. People here are really reluctant to change - they've been using the old system for 2 years, and I'll need to train them to use Cerberus. I'm confident it'll streamline operations, but people will be more than happy to point out the differences and raise hell about them. They'll fight each difference and each function. My guess is it'll be a good half year before they are 'happy' with Cerb4 as compared to the one we are using now. Sorry if that is a bleak picture, but I don't think, as a manager, that the story is too different in other helpdesk scenarios.

Basically, a lot of the people who will be using this simply will not adapt to any change without saying 'send me to training' or 'I don't understand this, I want to use the older system.' I try and promote different ways of adapting to such changes, but it's a difficult battle right now so we have to be very careful about updating core services.

Again, I can sell the existing system to my people, but they'll jump ship quicker than you can blink with these updates. I was just about ready to sell them on build, errmm, 420 (or something) before the December vacation and if I had, they would have completely been up in arms about build 500 - too much change too soon.

Maybe I'm approaching this wrong? Is SVN more the developmental way of updating cerberus? I just want to get a stable version (which this is), patches for things as they come up (like the CC issue we ran into) that doesn't effect existing features, and then look at a 4.1 or 4.2 or what-have-you that we can evaluate and then prep our people for 'exciting new features' when we feel they are ready for the change.