We all hate picking favorites in our personal life, making plans with one friend and having to cancel your evening with the other. But in the business world it comes with the territory, whether we like it or not. If your organization is anything like ours, you can’t always treat your clients on a first come, first served basis. When important contacts need an issue resolved, you handle their problem as quickly as possible, and then move onto the rest of your contacts. And there really is no greater example of this constant decision making process for an organization, than one who handles large volumes of e-mail everyday.

Cerb4 addresses the problem of prioritizing mail by giving you the ability to rank contacts in order of importance. The higher the rank, the more valuable it is to respond to them sooner. The general idea is, if you can quickly identify which tickets came from your most important clients, then you can easily focus your organization’s attention to replying to them first. The way Cerb4 puts all of this into action is through service levels.

Configuring “service levels” starts with creating your levels, or ranks, of importance. These levels represent your organization’s service hierarchy, the higher a name is on the list the more important it is to your organization.

To create your own service levels, click ‘helpdesk setup’, the ‘Service Levels’ tab, and then add your levels one by one. When you are done, change the order of the list by adjusting the”Priority’ number — ’100′ being the most important and ’1′ being the least. These numbers are arbitrary so just make sure they decrease in value and you’ll be fine.

As you can see the names I’ve chosen are a bit silly, you will want to pick names more meaningful to your organization. These titles were not designed to be realistic so they could clearly show the relationship between a priority number and its rank, relative to the one below it. Remember these ranks don’t have any real meaning for the Helpdesk, they are simply a reminder to your organization on what “level of contacts” to respond to first.

Now that you have your service levels ready, the last part is adding contacts from your address book to one of the levels. You can add a specific individual’s address to a service level or the client’s entire organization (all the associated addresses will inherit it). As you know there is a number of places to open a contact’s information, you could do this from the ‘address book’ or just about anywhere by clicking an e-mail address, so find an address and pick a service level from the “edit contact” window.

And that should be enough to “promote” this contact’s tickets to the head of the pack. If your contact has any open tickets the next time you go to Mail Overview, ‘Service Levels’ will appear in the sidebar with a level and a ticket count. As you start delegating more and more contacts to your priority hierarchy, you will see longer and longer prioritized lists.

Now simply have your team tackle the service levels from top to bottom, and you will be giving your most important contacts the fastest response times possible.

So moral of the story is, if your organization constantly finds itself with a “laundry list” of tickets, let service levels help you decide what to fold & put away first.

-joegeck@wgm

While I’ve written about Cerb4′s own Long-Term vs. Short-Term Caching before, I haven’t really explained Cerb4′s support for advanced caching strategies like Memcached.

I sat down this afternoon and wrote some notes on using both APC and Memcached to turbo-charge your helpdesk page loads: http://wiki.cerb4.com/wiki/Performance

Keep in mind that both of these options will likely require you to have administrator-level access on your server.  If that access is above your pay-grade, and you haven’t felt like performance issues have been holding you back, then just tuck this tip away in the back of your mind for the day that it comes up.

(APC and Memcached are also two more benefits of hosting your helpdesk on our On-Demand platform.)

Enjoy the tips!  Feel free to comment if you get stuck following the instructions.

-Jeff@WGM

Someone in the forums recently discovered “overdue” tickets by accident, which was more than enough to convince me ticket response times needed better documentation. First things first, it’s best to not think of response times as a due date on a calendar, more like a reminder for when tickets have gone too long in the Helpdesk unanswered. Keeping that in mind, Cerb4 is designed so that you add response times to individual buckets where all the tickets inside inherit the target times. Considering these are not necessarily hard deadlines it would be a lot of extra work to set reminders for every single ticket.

To configure things, click ‘group setup’, pick a group, and set your ‘Response’ time in hours from the ‘Buckets’ tab.

Now any tickets in that bucket which have not been replied to before the response target, will be “flagged” overdue for you to see. “Flagged” is a bit of a misnomer, in reality overdue tickets are not treated any differently by the Helpdesk. The only noticeable change you will see is in the ‘Updated’ column of your ticket lists. Tickets that are overdue will be red, so if a ticket was updated ’2h ago’ and that buckets response time is set for 1 hour…

Hopefully red dates serve as little more than a “tap on the shoulder” to get you working on those aging tickets!

-joegeck@wgm

Are you using e-mail notifications already? Tried to, but didn’t understand them? Never even heard of them? For a small cross-section of the community, notifications are a popular subject; but for everybody else, not so much. However, these loyal users are constantly leaving us feedback on how to improve things, making it clear that notifications can be a more viable feature for the rest of us. Unfortunately, no matter how great notifications are they will never be widely adopted unless everyone understands why they’re useful. Today I’m going to resolve this problem by giving you the first lecture on E-mail Notifications.

The 101

Let’s go over what e-mail notifications are before we tackle anything else. When a worker signs up for notifications they are asking to receive copies of new helpdesk messages at an external e-mail address. Notifications give workers the power to “watch” the helpdesk for any new messages without being logged into Cerb4. But this goes beyond just reading new mail, as you can also use your preferred e-mail client to reply back to your customers directly without using the helpdesk interface. Don’t consider this “bypassing” Cerb4 though, as even when you use Gmail or Yahoo to answer e-mails, you’re still technically using the helpdesk. That’s because your replies are automatically routed back through the helpdesk before they’re sent to the customer. You still get all the benefits of using Cerb4:

• E-mail headers are “scrubbed” to protect individual worker addresses by replacing them with your organization’s public addresses. So instead of the customer getting a reply from joe@yahoo, it will be from support@mycompany.
• All messages in the conversation are self-contained within a ticket. You can continue to keep tabs on a customer with all the meta-data that tickets offer: comments, tasks, custom fields, etc.
• All your mail is shared by the entire organization, encouraging your staff to distribute the workload when dealing with e-mail. Anyone can reply to a ticket, everyone can see the reply, and anybody can search the history.

Use Cases

You may be asking, “Why use the software at all if I can read and reply from my personal e-mail account?”. As I said before, you get the benefits of a helpdesk with the freedom to respond to e-mail from your favorite application.  Maybe your workers don’t have access to a web browser during certain parts of the day, or prefer answering e-mails on their mobile phones, or simply don’t like the helpdesk interface. The key point about e-mail notifications is that workers turn them on because they want to be notified when something new happens — and conventional e-mail clients are much better about this than the web browser. For some concrete examples, let’s go over a couple of scenarios where notifications can make life for your workers easier.

Managers/Project Leads: Notifications are the perfect fit for your higher-ups that need to supervise all mail entering and leaving the helpdesk. Instead of forcing managers to constantly check the ‘Overview’ sidebar for new tickets, they can allow notifications to queue up in their normal inbox. If you combine Cerb4′s notifications with something like Gmail Notifier workers can be alerted to new tickets instantly. Off-site managers may find notifications useful too if they usually answer e-mail from their mobile phone.

Low volume mail: Every organization probably has a couple of groups or buckets in Cerb4 that just don’t get a lot of mail. Sometimes they can go weeks or even months before you see any new messages, and by that time you forget to check. Notifications can be a great tool for keeping tabs on things — you’ll be certain no mail sneaks by under the radar.

Setup

Let’s wrap things up by going over setup. Cerb4 gives each worker the freedom to configure e-mail notifications according to their needs; so e-mail notifications are configured from the worker’s My Account page. Setup is fairly straightforward and consists of two parts: choosing an e-mail address to receive notifications and specifying which events to watch. Click ‘my account’ in the top right corner from any page.

You can add new e-mail addresses from the ‘General’ tab. The ‘E-mail Notifications’ tab allows workers to choose which groups and buckets to monitor, and for which events (incoming, outgoing, etc).

That should help you decide when e-mail notifications may let you read and respond to conversations quicker without using the web-based interface.  In the next part we’ll use “watcher commands” to give the helpdesk remote instructions through e-mail.

-joegeck@wgm & Jeff@WGM

Regarding The Fundamentals Of Our Cerby Are Strong:
we are not sure what to make of this message and find it, frankly, alarming. Are we to understand that your company and your product are in danger and that we had better move to another product? To us, this message sounds like a cry for help, or at least it rings alarm bells.
-a concerned Cerb4 customer

Hey there,

The issue is that everything we can do from our end — price, functionality, value, philosophy — has the risk of being overshadowed by the Market’s irrational, paralyzing fear of financial Armageddon.

As I mentioned in the very first paragraph of that message, our company tends to experience an upside when budgets are tight since our software is relatively inexpensive and provides a great value.  The only negative implication I can find in the message we sent out is the ‘downside’ note that we’re not winning every sale — who does in any situation?

We’ve always had the risk, when getting most of our income from one-time sales, that we’d someday saturate our niche.  Realizing that inevitability, we’ve built up our On-Demand option that provides ongoing services (e.g. application hosting, backups, optimization, support, custom development) for monthly residuals.  While that’s more of a time investment than simply selling licenses to run on your hardware, it’s also more stable and creates a stronger “outsource” partnership between us and our clients.  It’s leasing out our experience instead of depending entirely on software which was written in the past.

We’re not in grave financial danger — we could run the company from a coffee shop on a shared laptop if it came down to it.  Unless we start making a lot of silly mistakes, or the sky actually does fall, it’s not going to get that bad.

If we lose the pulse of the community and stop producing software that you feel is worth what you’re paying, then that would be a very appropriate point for you to jump overboard.  However, if you’re simply worried that some external forces will dissolve our company and force us into unemployment, you can worry when we start giving everything away for free and we stop writing spry responses to your e-mails of concern. ;)

-Jeff@WGM

(This is a re-post of a broadcast to all registered Cerb4 forum members this evening.)

We’ve had many prospective Cerb4 users bring up the economic turmoil in their conversations with us lately.  Sometimes we benefit, as many people are looking to lower their suffocating licensing costs from enterprise systems implemented in the “boom” times; and sometimes we’re losing out, as others decide to “tough it out” with their existing patchwork systems, even though they’d prefer to rollout something more streamlined and coherent.

In a way, we’re energized.  In an economic climate like this, we have a chance to prove to you that we’re not simply exchanging a one-off copy of pre-built software for a fist-full of your hard-earned revenue.  We’re also committed to being a partner through the tough times, mediating helpful tips and efficient practices from an entire community; still giving you the greatest return on your investment with us.

Unlike the economy, Cerb4 is in an incredibly healthy technical position.  The transition between 3.6 and 4.0 is where the dusty skeletons fell out of our closet and were given a proper burial.  If you think there may be some areas where you can shift more of your workload to the project, we’d love to hear about it.

In the meantime, make sure you’ve added the Cerb4 Blog to your RSS news reader.  We’ll continue to share more tips and insight than ever.

Cerb4 Blog:
http://www.cerb4.com/blog/

Cerb4 Wiki (Collaborative Docs):
http://wiki.cerb4.com/wiki/

Thanks for being a part of the project!

-Jeff@WGM

You can’t help but run into some issues in your first weeks of test driving Cerb4, whether you’re trying to do something trivial or just playing around to see how a feature works. Once you find a potential “bug” you’ll probably start by searching the forums, then writing in to support and maybe even adding it to JIRA yourself. But don’t pull the fire alarm too quickly! The problem is there’s a lot going on beneath the surface that you may not be aware of.

What’s the point of all this, you ask?

To show you why things are not working like you would expect. Because if you’re familiar with how the Helpdesk works under the hood, you will know immediately if you fell on a real bug or a false positive. Hopefully this will all make sense once I shed light on a few of these important behaviors in Cerb4.

Behavior #1: “Deleted” tickets are only removed from the Helpdesk after a set number of days with no new messages.

I’ve seen this one throw a few users for a loop in the past, who have stumbled on their “deleted” tickets still in the Helpdesk. Maybe they did a search for an old ticket ID, or were browsing all their tickets and noticed some X’d out. To see if you currently have any deleted tickets, do a search where ‘deleted = true (1)’.

Every 24 hours the Helpdesk purges deleted tickets, where 7 days have passed with no new messages. This is the default but If you want to adjust how often it wipes the Helpdesk, and how many days have to pass, click ‘helpdesk setup’, the ‘Scheduler’ tab and then the ‘Maintenance‘ link.

Holding onto deleted tickets for a few days definitely has its benefits, for one thing you get a “do over” in case you accidentally dismissed a ticket prematurely. But it’s nice to do some spring cleaning once in a while. Here’s a tip for reducing the size of your Cerb4 database, start by reporting all spam and deleting any irrelevant tickets you no longer need. Then under “Maintenance Settings”, set the ‘days of inactivity’ to zero, save changes and click ‘run now‘. Don’t forget to change it back up to a reasonable number of days when you’re done!

Behavior #2: Flood protection potentially stops auto-replies from being sent by the Helpdesk.

I’ll assume everyone is acquainted with flood protection and how vital it can be in preventing mail loops, e.g. two addresses auto-replying to each other back and forth. This is one of those behaviors users are surely familiar with, but simply forget about when testing their live Helpdesk.

I see this oversight pop up every so often in our forums. A person is configuring the group auto-response settings, and is experimenting to see if the “new ticket” and “close ticket” responses are working correctly.

To actually test it, they usually send a handful of tickets from their test e-mail address into the Helpdesk. By rapidly sending in new tickets and immediately closing them, they ultimately flood the Helpdesk. Of course at that point, they mistakenly think Cerb4 is broken when it ceases to consistently trigger auto-responses. In a real world scenario, any spammy addresses that flood the Helpdesk will be ignored and your real customers will get your auto-responses.

Behavior #3: E-mailing the Helpdesk from a worker address will cause “role reversal” issues, e.g. when the worker address replies, the Helpdesk thinks it replied.

Your organization’s workers are defined by an e-mail address in the Helpdesk, that’s their login to the system, their unique identifier if you will. What if you start using a designated worker address as an external test address for sending mail into the Helpdesk — is it too much of a stretch to assume some interesting results might occur?

This causes the “role reversal” problem: the Helpdesk thinks workers are sending outgoing messages when they are actually incoming messages. And after a few replies between your Helpdesk and your outside (worker) address, you’ll start seeing issues mysteriously pop up.

There’s even a couple of concrete examples in JIRA already that highlight this behavior. Look familiar?

CHD-570: Incoming/Outgoing labels are switched when an e-mail is sent to the Helpdesk from a worker address

CHD-617: Worker reply to Autoresponse email generates a new ticket

Bottom line, avoid using worker addresses as test recipients, otherwise you’ll start seeing unexpected bugs left and right.

So that’s it! If nothing else, now you can explain away the odd issues you may see when playing around with Cerb4. Just remember the Helpdesk isn’t broken, that’s by design.

-joegeck@wgm

We’ve been a little quiet on the development front for the past couple weeks since we’ve been busy helping people upgrade from earlier versions of Cerberus Helpdesk to Cerb4.  During these migrations, we grew frustrated with the discontinuous tools we had provided to import tickets, contacts, and knowledgebase articles into the new version.  We took our frustrations as a blueprint and designed a new, consistent Import/Export (ImpEx) system to handle future migrations.  We also designed the system to be extensible, so third-party developers could quickly build on top of our work to create exporters from additional sources.

As of the latest Cerb4 stable release, you can now use the new ImpEx tools to import content into your helpdesk from pretty much anywhere.  The new tools introduce a universal XML format to import whole tickets at once (including meta, content, attachments, comments, and all).

This first release of the new ImpEx tools supports exporting directly from Cerb 2.7 or Cerb 3.6.  We’ll also be listening closely to community feedback to expand the roster of official exporters in subsequent updates.

User Docs

About the new ImpEx Tools:

http://wiki.cerb4.com/wiki/ImpEx

Exporting from Cerb2/Cerb3 to Cerb4:

http://wiki.cerb4.com/wiki/ImpEx:Cerb3Export

Developer Docs

Writing your own export driver:

http://wiki.cerb4.com/wiki/ImpEx:WritingDrivers

http://wiki.cerb4.com/wiki/ImpEx:OutputXML

Enjoy!

-Jeff@WGM

The wiki now contains a comprehensive guide about backing up your helpdesk data:
http://wiki.cerb4.com/wiki/Backups

-Jeff@WGM

The point of having a publicly editable wiki for documentation, opposed to static HTML or PDFs, is to encourage a diverse community to share and cross-pollinate tips, tricks, fixes, and best practices.  If someone runs into trouble following a set of instructions, they can leave a quick note to protect the next person from wasting an hour of their life banging their head against the wall about the same problem.

When we first launched the wiki, we knew we would love for everyone to share their insight; but we weren’t sure how many people would actually contribute.  We’ve been pleasantly surprised by the result!

Because our first “go” at the wiki was an experiment, information wasn’t organized as well as it could have been.  We just finished a quick cleanup that makes it easier to both browse and extend the available information.

Of particular note is the new section on “Best Practices”, covering important (but previously buried) topics like backups and security.

If you think you could do a better job somewhere, feel free to put on your hard hat and start ripping up the sidewalk.

http://wiki.cerb4.com/wiki/

-Jeff@WGM