How to "Flag" tix so others will not touch?

[todd999]

We flag the tix as soon as we open them so 2 workers will not both reply to the same tix..

How do we do this in v4

[jstanden]

Hey Todd,

The replacement for "flagging" in Cerb4 is the Last/Next Worker/Action system.

Last Action: New Ticket, Customer Reply, Worker Reply
Next Action: What needs to happen to advance it?
Last Worker: Who acted last on the worker side?
Next Worker: Who should act next?

If you set a Next Worker on the ticket (which you can do from Preview, Display->Properties or the Reply page) then other workers should be sufficiently protected from double replies.

This also lets you assign work to other people, and filter to-do work by a specific person or just anything unassigned.

We'll probably still add some functionality for more proactive warning when two or more workers are on the same ticket and one of them is already replying.

Thanks!

[todd999]

so how do I "take a ticket" as soon as I ioen it to add my self as "next worker"?

How do I set a view to show only unclaimed tickets with no next worker?

How do i make a rule to Auto set one person to be the next worker for a set of new tickets?

[jstanden]

so how do I "take a ticket" as soon as I ioen it to add my self as "next worker"?

When you're the Next Worker you've already reserved the ticket.

How do I set a view to show only unclaimed tickets with no next worker?

Custom Workspaces.


Click 'mail' in the top menu
Click 'my workspaces'
Click 'add new worklist'
List Title: Unassigned Tickets
Workspace Title: Dispatch HQ (or anything you want)
Click 'Save Changes'
Click 'customize' on the right-side of your new 'Unassigned Tickets' list.
Add Column:
Next Worker
Add Filter:
Next Worker, in list, 'Nobody'
Click "Save Changes"You can tweak that same basic process to report anything you want in a new workspace. Remember that you can add multiple worklists to a workspace (so you could show Unassigned and Assigned lists, etc.)

How do i make a rule to Auto set one person to be the next worker for a set of new tickets?

At the moment you can't automate this, but we'll definitely provide some kind of 'Quick Assign' feature again so people don't need to grab things from the lists.

I added this back to the roadmap for you:
http://www.wgmdev.com/jira/browse/CHD-211

Thanks!

[cbtrussell]

The replacement for "flagging" in Cerb4 is the Last/Next Worker/Action system.Stuff like this causes me to think you guys honestly make an effort to see who can come up with the most unintuitive concept to further confuse your existing customer base from one version of Cerberus to the next. First we have the complete cluster that was the original v3.0, now we have another completely unexpected change in direction that will require not only a re-training for our internal users, but also all of the customers we've referred to Cerberus Helpdesk. I'm not quite sure why each successive version of Cerberus requires such significant modifications to established procedures & workflows mandated by the previous version. It's maddening, reflects poorly on us as consultants when we recommend your software, and frankly - although I'm very pleased with our customized version of 3.4 - makes me wonder if we need to hitch our wagon to another horse.

[jstanden]

I'm not quite sure why each successive version of Cerberus requires such significant modifications to established procedures & workflows mandated by the previous version.

Hey there,

I sympathize moderately, but you need to understand a couple things (and I'll be frank):
The bigger issue is that past versions of Cerberus Helpdesk took far more steps and were far more arcane. If we followed your logic, the right thing for us to do would be never improve the functionality if it involved changing it. We're huge believers in incremental improvements (based heavily on real-world usage) -- so I can't agree with you there. Things are going to change, and we generally wait until major releases (3.x->4.x) to do so.
The focus of 4.0 is providing the core functionality of the helpdesk as the default installation. That's why my example above takes a couple clicks to convey the point -- because you're using blocks of functionality to accomplish something rather than a specific feature. This approach will pay dividends as developers (at WGM and in the community) are able to extend the helpdesk for their specific needs/vision. That's when you'll see one-click functionality doing your repetitive daily tasks for you.
The major difference in 4.0 is the framework/code being rewritten and organized for at least 2 more years of maintenance (and community plugins). After 5 years, the original codebase (1.x->3.x) was completely out of control.It's ironic that you're missing the point here. It's exactly because the past versions were hard-coded with our ideas on implementation that people found them confusing. And it's for that reason 4.0 doesn't try to codify "the way" as we see it this week, but gives everybody the tools (in both functionality and the API) to build off it based on their specific needs.

Before specific ideas are presented as to how things like "flagging" should work, naturally some actions are going to seem like the "long way" -- because you aren't being forced to do it any particular way. That's the whole point of plugins and making a rather clean "core" environment to add them to.

There's nothing wrong with you staying on 3.x in the meantime until you get a better idea for how the new framework will allow rapid development, customization and the ability to easily turn features on/off to customize your environment.

...although I'm very pleased with our customized version of 3.4 - makes me wonder if we need to hitch our wagon to another horse.That's your decision to make, of course. But I'd hate to see you leave with a mindset that hasn't really grasped what we're trying to do with 4.0 yet -- especially when you mention customizations (the biggest advantage of 4.0's rewrite).

I genuinely feel like we're just getting started in the way we should have done things all along. It took a lot of real-world use (5+ yrs) in many environments (18,000+) to really see the big picture.

If your contention is that the product changes every couple years, it should at least pacify you that the recent development is ensuring the core elements of the helpdesk are simple and concise enough that they won't continue to change so radically. From that starting point, as a consultant, you can combine the plugins a particular client needs, without confusing them with superfluous elements, and with the confidence that your own plugins are forward-compatible with our future development. That's the entire point.

It's not my intention to be preachy or contentious here -- as I said above, I sympathize with the situation you feel you're in.

[jstanden]

...First we have the complete cluster that was the original v3.0, now we have another completely unexpected change in direction that will require not only a re-training for our internal users, but also all of the customers we've referred to Cerberus Helpdesk...I have additional thoughts on this.

The 2.x->3.x transition was such a problem because we specifically avoided trying to change things too significantly. So we ended up with a hybrid of what we wanted to do and what we had already done. We discovered straddling that line of trying to appease people's resistance to change, despite our fresh ideas, was far worse than introducing the best ideas.

With 4.x we just started over and took a lot of time to re-examine what each feature was contributing and trying to do. We committed to accepting the best solutions we could think of regardless of how discontinuous they were.

If you really object to us thinking about how to make everything better with a clear-head so we don't repeat the 2.x->3.x fiasco again, then keep using 3.x. If your ecosystem requires things don't change regularly as new information is uncovered, then this is probably not your ideal project.

Hopefully, though, you realize that it's much better to have us aggregating the experiences of thousands of people (and hundreds of thousands of requests and support issues) into the software each new major version -- even if better means different.

I understand that it frustrates some people to have to retrain internal users, but part of the problem is the previous software requiring so much training in the first place (because the concepts were so fragmented).

Improvement requires change. And I want to put forward the opinion again that some of the greatest improvements in 4.0 aren't even really being put to use yet -- the framework and plugin system.

If you don't know how to read code, grab somebody you trust who does. And have them scan through the Cerb3 and Cerb4 codebases.

[todd999]

Still no answer.

In v3 when you open a ticket you just click "take Ticket" and it is flaged FAST

in v4 you need to open the ticket then open a tab and then select a drop down and then click save... and hope another person did not open it and start working on it while you were doing this slow process..

this is a show stopper for us.. we can not upgrade and risk 2 agents working on the same ticket at the same time.

In our org each worker has a dash with their flagged tix on top and all un flagged tix below by mailbox.

Too much risk of a problem with out a FAST way to Take a ticket..

I look forward to a solution... The old way worked well...

-Todd

[neenach2002]

If you click reply you can set the next worker there.

[todd999]

We do not reply to all tickets.. some require other action...

a phone call or other action...

we need a way to "take a ticket"

[neenach2002]

I am working on a mod for this now...

[jstanden]

Hey Todd,

I've talked to Brenan@WGM and Neenach about this a bit. I agree that it's too many steps to 'Take' a ticket. It was originally designed this way with a 'Quick Assign' dispatch mode in mind, but we didn't get around to that before the beta.

I'll go ahead and commit a tweak for quickly assigning a Next Worker to tickets from worklists:
http://www.wgmdev.com/jira/browse/CHD-262

I'd still like to bring in the Quick Assign feature so workers/dispatchers aren't having to manually assign tickets from lists. This would also completely get rid of two people taking the same tickets. It's just waiting on a simple tweak to bring in SLA-style customer priorities (so Quick Assign knows what order to assign work in). Quick Assign is open for tracking here: http://www.wgmdev.com/jira/browse/CHD-211

[todd999]

Thanks!
Yes a good quick assign would be a blessing

What is we could auto assign tickets to the people who are working the fastest...

for example:

agent A and Agent B both have 30 tickets....

A closes 15 tix in the same time B closes 5 tix

Auto assign 10 to A and just 5 to B to insure that tix are closed most quickly but the fastest agent and do not sit and wait for an agent who is stuck on one hard ticket that will slow them down..

[jstanden]

Yeah, that definitely makes sense for a dispatch environment where work is handed out.

The other situation is where your fast workers are simply telling the system "I'm done, give me more!" -- then it's automatically throttled without having to keep track of how quickly they're working.