What's holding us back from Cerb4

[bbillings]

We're evaluating the jump between 3.5 and 4.0, and there are a few must-have items before we can make the switch. I realize a few of these are already in the works, just figured I would throw our hat into the ring as well in case someone worked out a solution already. If not, they're just another vote for priority.

1. Multibyte character support - Currently extended ASCII characters cause Cerberus 3.5 to clip E-Mails from customers at the offending character. Obviously this is a high priority update for us, and our big reason for updating to 4.0. Backslashes getting stripped out of outgoing E-Mails is another issue as well, Cerberus 3.5 doesn't seems to take kindly to magic quotes in PHP which would be the quickest fix. For now we just double-backslash which basically does the same thing.

2. Custom text fields - I actually put in a hack to apply a defined set of fields on every new ticket created in 3.5, we use them to mark the product and version information for later analysis. A process to import these from 3.x would also be quite welcome since a heterogeneous database join would not be a fun afternoon.

3. Customer info when viewing ticket - It was nice having the contact information on the mail view page. Knowing who the primary ticket contact name is, the associated company, and additionally a phone number would be extremely helpful since we often call customers back, not just E-Mail. The address book link also does not appear to have a place to even store phone numbers for individual contacts. If this is a custom field fix, that's fine, just so long as we have all the same functionality with custom fields (Search criteria, etc) as the stock field set I'm happy.

4. Response/notes display order - The comments from 3.5 is another critical feature for us. We often have phone conversations with customers, and use the comments to include the highlights and action items. Often we will have multiple E-Mails and comments within the same ticket. With the notes being separated and the whole chronological order being out-of-sorts, the notes capability is near useless in this regard. This is a big show-stopper for us. I suppose I can always hack the individual page, although I'd like to avoid changes that will be removed on updates.

5. Creating new tickets - I see a way of sending an outgoing messages in 4.0, although I don't see a way to create an incoming message from a new phone support request. I've hacked 3.5 so that the new ticket form automatically has the "don't send autoresponses" option set, so our current phone support process goes as follows:

a. Agent receives call
b. Agent creates new ticket using existing address lookup "hack" for 3.5
c. Agent enters call information into ticket body field
d. Agent resolves phone issue, submits ticket
e. Agent appends any comments as required
f. Agent closes ticket, which sends a closure notice to the customer

This way the customer sees that we logged their phone item, and closed the respective ticket. If the create option in 4.0 actually does this, the field names are very misleading as to their actual purpose.

6. "Move to" option field - It would be nice if the move to option field was organized more like the filter criteria display. Currently it lists all inbox options available, then repeats the group name with each non-Inbox bucket for that group underneath. Seems like it would be more user friendly to show something like:

Support
- Inbox
- Bug Report
- Feature Request
Sales
- Inbox
- Quotes

I should really say this item is minor, it is a bit of a stretch to say this would prevent us from rolling out 4.0 in production.

7. Waiting on customer flag - In 3.5, we filter out all of the inactive tickets from our main workspaces. For us, responding to a customer doesn't always mean the ball is back in the customer's court. Since that is the case, we can't use the last/next action filters to accomplish the same task of creating a "to-do" list via a workspace filter set. We can't close these tickets since we use an autoresponse to send a message that we feel the ticket has been resolved, which would obviously upset customers and send the wrong message.


Overall 4.0 coming along nicely. I'm really excited about the plug-in possibilities, and the AJAX really seems to smooth out the interface and make the software seem snappier. I'd say it's about 90% of the way there, we just need that last 10% before we can consider a full update to the new release. Thanks guys!

[bbillings]

Whoa, sorry about that! My post should have been a new ticket, not a reply. Must have been asleep at the wheel there!

Feel free to edit as required, mea culpa!

[jstanden]

Whoa, sorry about that! My post should have been a new ticket, not a reply. Must have been asleep at the wheel there!

No problem! Easy enough to fix. I just moved this to its own thread, I'll go ahead and reply in a couple minutes. :)

[bbillings]

Awesome, thanks!

[jstanden]

#1 (Multibyte): We require the 'mbstring' extension in Cerb4 to provide multibyte support. Currently this isn't in full effect yet, but the requirement is there to make the transition easy the moment we want to flip the proverbial switch.

Magic_quotes shouldn't be an issue in Cerb4 either, we run everything through Devblocks::importGPC() which takes variables and typecasts, defaults and cleans up magic_quotes silliness.

#2 (Custom Fields): Custom fields haven't been integrated into the Cerb4 concepts yet, but it's one of the major things we're working on. Being able to instance custom field groups was a nice idea on paper, but they ended up getting unwieldy pretty fast. We need a nice clean way to associate custom fields with particular groups/buckets so it can be handled automatically. We also need it to be simple enough that the Support Center can directly fill in this information (and count on on specific fields being present).

Community discussion is definitely welcome here. If we all knew exactly what we wanted out of custom fields this time around we could knock the code out ridiculously fast.

#3 (Address Book on Display Ticket): I'm glad you noticed the "Address Book" link for each message on Display Ticket. You're absolutely right that 'Phone' is missing. I added the task to the roadmap:
http://www.wgmdev.com/jira/browse/CHD-358

#4 (Notes vs Comments): More thoughts can go into chronological comments vs. notes. There is probably room for both concepts.

As for importing past comments, that won't be an issue when we have a feature to import that data into.

http://www.wgmdev.com/jira/browse/CHD-359

#5 (Create Ticket from Call): Up to this point with 4.0 we've suggested that people send a quick outgoing summary of the call to the requester. I can see where the lack of a "don't send a copy" feature is causing trouble.

Our internal mail API supports not sending mail when creating a ticket, so we should be able to expose this to the UI pretty easily.

In the latest updates we've also added the "Next Action" panel to Compose Mail, which allows you to quickly close the new ticket without having to go dig for it.

http://www.wgmdev.com/jira/browse/CHD-360

#6 (Move To Dropdown): The Group/Bucket dropdown shows Groups together at the top to make it much quicker to simply hand off a ticket without having to think about how other groups organize their workload. We don't show buckets from other groups in those dropdowns unless you're a member of a given group.

It would be trivial to change the dropdown to do what you ask, but having to scroll through a huge list of buckets to get to my desired group would probably slow down the interaction of 90% of my ticket moves.

This is probably your only suggestion I am not in total agreement with, because it's too easy to assume every worker is blessed with the same omniscience we feel as administrators/managers. In practical reality, almost any worker can sort out "Sales" or "Billing" issues. They shouldn't have to think beyond that to move on with their day. They certainly shouldn't have to scroll past 50 buckets that aren't relevant to their work.

We offer both options (quick or detailed moves), but it's optimized for quick moves and less scrolling.

#7 (Waiting on Reply): That's a good point. It's the same reason we added "Next Action" and we no longer hide "Outgoing" tickets in the Overview lists. The 'Waiting' distinction shouldn't solely be on Outgoing/Incoming, but on Closed/Open. We don't specifically separate Closed/Resolved (meaning Waiting or Completed), but Closed operates the same way for both.

All closed tickets are technically waiting for a reply. We'd really like to avoid juggling another property for it if at all possible. A custom field could return this functionality for you without us forcing the more complicated workflow on everyone else by default.

Overall 4.0 coming along nicely. I'm really excited about the plug-in possibilities, and the AJAX really seems to smooth out the interface and make the software seem snappier. I'd say it's about 90% of the way there, we just need that last 10% before we can consider a full update to the new release.

Thanks! I'm glad you've got an eye on the big picture too. Tweaking and adjusting things is a natural part of the process and it's incredibly easy for us to do.

Over the past 9 months we weren't trying to design features that magically worked perfectly for everyone right "out of the box". We know the best way to do that is to engage you guys. We spent our time rewriting the foundation to ensure change would be cheap and painless, and stay that way even after integrating a lot of this post-relaunch feedback.

I'm really excited by the plugin possibilities too. I also think it's possible that Devblocks (our PHP5 platform) will be a bigger deal than Cerberus in a year or so. That won't diminish our infatuation with Cerb though -- I have a feeling that's to the death. ;)

[bbillings]

Community discussion is definitely welcome here. If we all knew exactly what we wanted out of custom fields this time around we could knock the code out ridiculously fast.

I obviously can't speak for everyone, although I would say you hit the nail pretty much on the head with 3.x. The only area I can see would be automatic value assignment to the fields upon receipt, except that is an entirely different can of worms

More thoughts can go into chronological comments vs. notes. There is probably room for both concepts.

As for importing past comments, that won't be an issue when we have a feature to import that data into.

Possibly, although I really see the chronological comments superseding the notes feature for those that go that route. My understanding of the notes feature is to have a discussion in regards to the ticket. To me it makes sense to have said conversations around/inline with the reference E-Mails. Of course that makes the assumption that comments/notes are being used in that capacity.

Up to this point with 4.0 we've suggested that people send a quick outgoing summary of the call to the requester. I can see where the lack of a "don't send a copy" feature is causing trouble.

Our internal mail API supports not sending mail when creating a ticket, so we should be able to expose this to the UI pretty easily.


Right, since these "E-Mails" are internal phone call summaries and likely contain internal notes (We don't open our system to the public), we just want to enter the call log and send a close notification to the customer.

All closed tickets are technically waiting for a reply. We'd really like to avoid juggling another property for it if at all possible. A custom field could return this functionality for you without us forcing the more complicated workflow on everyone else by default.

The only problem is that field is not changed when a customer replies. I suppose this will work if we use the custom field along with the last responder aspect, it's just a bit kludgey. The other option I can see is closing a ticket with the option for "Close ticket, no auto-reply." That way support can keep their plate clear without sending false resolved notifications.

[jstanden]

My understanding of the notes feature is to have a discussion in regards to the ticket.

Notes are a mini-discussion related to a specific message.

For example: We'll often add a note to a message if a customer provided login details for an installation. This calls attention to the specific message even if it's buried by more recent conversation. Otherwise we'd have to search and scroll a lot every time one of us picked up the ticket to work on it.

Once we're done with a particular piece of information like that, we nuke the note and the message collapses to be part of the archive. Any message you add a note to will always display as expanded in the thread.

Notes are meant to be created and deleted as progress happens on a ticket. They're essentially call-outs, and not meant to be a permanent part of the record.

The other option I can see is closing a ticket with the option for "Close ticket, no auto-reply." That way support can keep their plate clear without sending false resolved notifications.

Sure, that came up in 3.x as well. It would probably be best to always close silently, and offer another button to "Close & Resolve". I wouldn't make this part of the core project, but it's a pretty straightforward optional plugin.

[jstanden]

#3 Done: http://www.wgmdev.com/jira/browse/CHD-358

[bbillings]

Hey Jeff. Any updates on the unresolved items here?

[gglynn]

#5 (Create Ticket from Call): Up to this point with 4.0 we've suggested that people send a quick outgoing summary of the call to the requester. I can see where the lack of a "don't send a copy" feature is causing trouble.

Our internal mail API supports not sending mail when creating a ticket, so we should be able to expose this to the UI pretty easily.

In the latest updates we've also added the "Next Action" panel to Compose Mail, which allows you to quickly close the new ticket without having to go dig for it.

http://www.wgmdev.com/jira/browse/CHD-360



I've already voted for this one in JIRA, but I figured it couldn't hurt to bring it up here in this thread again.

[gglynn]

#4 (Notes vs Comments): More thoughts can go into chronological comments vs. notes. There is probably room for both concepts.

As for importing past comments, that won't be an issue when we have a feature to import that data into.

http://www.wgmdev.com/jira/browse/CHD-359


I've voted for this in JIRA, too, but here's a forum bump. We really need these inline comments back. Notes are neat, but as you've written elsewhere in this thread, they're not the same as the old comments, which are crucial to our workflow.


#5 (Create Ticket from Call): Up to this point with 4.0 we've suggested that people send a quick outgoing summary of the call to the requester. I can see where the lack of a "don't send a copy" feature is causing trouble.

Our internal mail API supports not sending mail when creating a ticket, so we should be able to expose this to the UI pretty easily.

In the latest updates we've also added the "Next Action" panel to Compose Mail, which allows you to quickly close the new ticket without having to go dig for it.

http://www.wgmdev.com/jira/browse/CHD-360


Another bump for this one, too, although I've hacked it together from what you had commented out in SVN and the code/template for the "compose" function.

[jstanden]

#5 is now implemented:
http://www.wgmdev.com/jira/browse/CHD-360

[joegeck]

#4 (Notes vs Comments): More thoughts can go into chronological comments vs. notes. There is probably room for both concepts.

As for importing past comments, that won't be an issue when we have a feature to import that data into.

http://www.wgmdev.com/jira/browse/CHD-359


Threaded inline comments are now in the stable branch as of 642 but I believe they may have been available a few builds ago.

You can turn on the ability to see all comments embedded alongside the messages in the ongoing conversation tab. As expected everything is in the proper chronological order so comments will appear in-between messages that came before and after.

To turn on this ability on a per worker basis click "my account" next to "sign off" and toggle ON "Show comments in the conversation".

[DBowsky]

#2 (Custom Fields): Custom fields haven't been integrated into the Cerb4 concepts yet, but it's one of the major things we're working on. Being able to instance custom field groups was a nice idea on paper, but they ended up getting unwieldy pretty fast. We need a nice clean way to associate custom fields with particular groups/buckets so it can be handled automatically. We also need it to be simple enough that the Support Center can directly fill in this information (and count on on specific fields being present).

Community discussion is definitely welcome here. If we all knew exactly what we wanted out of custom fields this time around we could knock the code out ridiculously fast.


I can see part of the issue being that it's impossible for you guys to predict how people are going to build their custom field sets, making it similarly impossible to code them into drop-down selections, reports, ticket list views, etc. Of course having the ability to do more with them is fairly essential, so perhaps some examples of what we'd like to see would be helpful.

For example, a couple of our teams have setup priority buckets (lacking an independent priority attribute that is not tied to a "customer." As I have mentioned before, I setup Cerberus for internal support teams so all of our "customers" are company employees and treated with the same theoretical SLA) while our "Facilities" guy just uses buckets for the few problem categories he works with and doesn't bother getting so granular as to use custom fields. In completely the opposite direction, another team has mostly forgone the use of buckets, and relied primarily on custom fields. Again, in order to circumvent the fact that all sla/priorities/due dates are tied to "customers" and not an independent ticket attribute, they have elected to create a "Due Date" custom field.

I think that their Due Date field is a good example to use for the types of operations that might be useful on custom fields. These guys are a business reporting team, so they get primarily requests for X information on/before Y date.

Here is the workflow they are seeking, which was possible in Cerb3, but not in 4:

1. Worker A gets a list of incoming tickets.
2. Selects (checkbox) a subset of that list, and used the cerb3 "Set Due Date" and "Set Priority" actions to apply those attributes to that list of tickets.
3. After repeating #2 on incoming tickets, then go reselct groups and assign them to the appropriate worker.

Now, I know that you can set Next Worker within the "peek" window for each individual ticket, but you can't set a group tickets selected from a list to an individual worker. Similarly you cannot set a custom field in either Peek view, or as a list view action. Meaning that in order for this group to use their all-important due date field, they have to go into each individual ticket.

Hopefully that is of some help as an example. Really the biggie is not being able to do anything with custom fields, save for to set them on tickets individually and perhaps report upon them later, is sort of a gimpy setup even though it has the potential to be a very robust system.

[joegeck]

Now, I know that you can set Next Worker within the "peek" window for each individual ticket, but you can't set a group tickets selected from a list to an individual worker.


Unless I'm reading this wrong, this is NOT true. It's possible it was added more recently, although I'm 99.9% positive it was well before June 27th -- when this comment was made. Just checkmark your tickets and then click 'bulk update', the 'Next Worker' drop-down is right there :)


Similarly you cannot set a custom field in either Peek view, or as a list view action. Meaning that in order for this group to use their all-important due date field, they have to go into each individual ticket.


This on the other hand is 100% accurate ;) Definitely something that will tremendously improve the overall workflow of quick ticket handling. As in DBowsky's example assuming you can rely on '(peek)' to easily determine the due date of a ticket in your worklist, it'd be to set a custom field before closing the window. Doubly so when you want to set a due date for a group of tickets using 'bulk update'. I'd imagine the developers could implement this but we'll have to hear from them; it's filed in our tracking portal for them to look into later.

http://www.wgmdev.com/jira/browse/CHD-807

As usual pop any feedback in the comments section!

[peter_mcc]

Just checkmark your tickets and then click 'bulk update', the 'Next Worker' drop-down is right there :)
and make sure you change it to "only checked" instead of the default "similar senders"...

peter