Refresh! is a new series dedicated to explaining older features that do not have formal documentation yet. We will be regularly pulling from 4.x features and finally posting some detailed tutorials for you, even if the feature itself hasn’t changed in Cerb5.

In some cases, such as this one, it’s also for replacing outdated documentation. “Feedback Capture” is an older feature we had back in the 4.x days, in fact we already blogged about it as part of a Sneak Peek. The problem is the accompanying video is stale and some of the assumptions it makes no longer apply (feedback lists).

This new article will be up to date and assumes you are on 5.1, although the deprecated functionality was actually dropped back in late 4.x, so it should apply to several versions. The latest written documentation will be available on the wiki.

http://wiki.cerb5.com/wiki/Feedback_Capture

The Cerb feedback tool is one of our more interesting ideas because it’s a “standalone” feature. Feedback can be quoted from anywhere and does not have to be linked to a specific ticket, task, time tracking entry, or even a contact in your address book. This means you can easily note anonymous feedback you didn’t necessarily receive through e-mail or over the phone; perhaps you found a favorable recommendation on a competitor’s forums or constructive criticism on a “product review” page.

To get started with feedback make sure you have it enabled (it’s not by default), click over to ‘helpdesk setup’, ‘Plugins & Features’.

Capturing Feedback

There’s two spots in the Helpdesk where there is a literal ‘Capture Feedback’ button — one being inside the main ‘Feedback’ tab under ‘activity’, the other being inside a ticket. We’ll go over each method individually.

Click ‘activity’, ‘Feedback’, then click the ‘Capture Feedback’ button.

Unlike capturing feedback through a ticket which pre-fills some of the information for you (more on that later), feedback through activity must be manually entered. I have filled in sample data to help make the example more clear, but normally you would start with a blank slate.

Because you can always replace the feedback fields when you “capture”, technically you can manually capture feedback from anywhere. Just copy and paste.

• Author E-mail is the individual you want to give credit to. If you don’t know the source of the quote, say an anonymous comment on a blog, you can leave this field empty. Feedback is “associated” with an e-mail address but not necessarily attached to it (Links?). What I mean by this is if you click the address from the address book (or any place you see a clickable customer@example.com) it will NOT have a link back to your feedback.
• Quote is the feedback itself. Copy and paste whatever text you want to save directly into this field. Warning any line breaks you would use to denote paragraphs will be lost in the list view (see list view screenshot below).
• Mood is exactly what it sounds like so I won’t try to come up with a fancy synonym for it. You can mark whether you feel this quote (opinion) represents you in a good light or a bad light, positively or negatively, or in the form of “praise” or “criticism”. Neutral is of course selected by default, for when there really isn’t a prevailing mood (“Our company switched to a different product”).
• Link is of course a URL to where the quote was grabbed from, could be a forum post, website, blog, or whatever you like. It is optional should you not need it.
• Regarding (multi-picklist) is a feedback custom field were using to categorize our company feedback. This is a non-standard field you would not normally see unless you created it ahead of time, but feedback like many other objects (tickets, tasks, opportunities) also supports custom fields. I created a “multi”-picklist field so we can tag any feedback that doesn’t fit neatly into a single category with multiple categories. When our feedback could be considered “Customer Support” or “Reliability”, we’ll do both.

When you’re all done, save, and your entry will be added to your ongoing list of feedback: red bubbles represent negative criticism, greens represent positive opinions, and grey is for neutral feedback. There is also a small (edit) link at the end of the quote [see black mouse pointer] should you need to make changes, including deleting the feedback entirely.

Unfortunately at the moment bulk update only lets you set custom field values.

Ticket Feedback

Outside of the main feedback tab, tickets are the only area to have a dedicated “Capture Feedback” button, where each message (e-mail) will have its own button. One of the unique aspects of ticket feedback is you can highlight any part of the message body and capture it immediately. Try selecting, or highlighting, part of your customer’s e-mails, (click ‘more’), then ‘Capture Feedback’.

Notice it pre-filled the three text boxes for you automatically (author e-mail, quote, and link). As we mentioned before all three can be changed to whatever you want prior to saving.

One final thing, captured feedback (like time tracking) automatically generates a ticket comment.

The comment may appear above or below the original message, depending on your “Read All” settings.

Although it usually requires a page refresh to see it, click “reload” in your browser, or the dedicated button at the top of the ticket.

-joegeck@wgm

Seats (5.0) is a type of “restriction” on workers but workers themselves are still a 4.x concept. The latest version of this document should always be available on the wiki.

http://wiki.cerb5.com/wiki/Workers_and_Seats

To understand seats you need to have a grasp on what a worker is first. Even though workers are the driving force behind a lot of other features we document, workers are usually only mentioned in passing (“Notify a worker with a comment”). In many cases we assume workers, as a concept, is borderline common sense and for many of us Cerb veterans it’s one of only a handful of topics that you could say that about, tickets being a close second. So before we look into how seats integrate with workers, let’s make it clear what a worker is in the Cerb universe.

Workers

The basic role of workers has not changed from the 4.x days, if you already know what a worker is feel free to skip ahead to seats.

• Conceptually, a worker is an employee for your company or organization who is going to get work done in the Helpdesk. In our system a worker could be a supervisor, a part-time employee, a contractor, or anyone who has a login account to the Helpdesk.

• Feature-wise, a worker is capable of answering e-mails, creating tasks, assigning work through comments, closing resolved tickets, or performing any major Helpdesk function the administrator allows them to (permissions?).

Worker leaving a comment on a ticket for another worker.

Whoever installs Cerb creates themselves as the first worker during setup and is given Administrator privileges. Once logged in for the first time they can add more workers by clicking over to the ‘helpdesk setup’, ‘Workers’ tab. New workers are registered in the system with an e-mail address and a password for their sign on credentials.

The *Phone field is a (worker) custom field. The * star is not necessary, we use that trick to make it stick out in screenshots.

Workers vs Users (Customers)

Our product like many others has two interfaces, a private “back-end” and a public “front-end”. We usually refer to the back-end as the Helpdesk and the front-end as the Support Center (or SC for short). Workers are given immediate login access to the Helpdesk, while the Support Center is for your users to use. We tend to refer to “users” differently depending on context such as “customer’s e-mail”, “address book contacts“, or “client ticket history” but the terminology is usually interchangeable.

• The previous couple of screenshots were images of the Helpdesk, it’s where all the magic happens behind the scenes. If you haven’t tried out Cerb yet and want to see the Helpdesk part of it in action, try out the on-demand demo. Inside the Helpdesk workers can see things like a client’s tickets, internal tasks, and time tracking reports. Only administrators have access to ‘helpdesk setup’ where they can install mail rules, configure auto-responses, and set worker permissions.
  • 
• The Support Center is a separate portal for your clients, that exists OUTSIDE of the Helpdesk (deploying an SC?). There are several optional modules you can install and most of them can be made public, or require a customer to register and log in through the Support Center first. The more popular ones include a Knowledgebase (FAQ), E-mail Contact Form (Open Ticket), and a client Ticket History. The Support Center administration is actually done inside the Helpdesk through the ‘Community Portals’ tab.
  • 

That’s not to say you can’t create a new Helpdesk worker account for a trust-worthy “customer”, or new Support Center user account for one of your “workers”; although the latter probably isn’t necessary because as a worker you have access to all opened tickets, including your own, inside the actual Helpdesk.

Hopefully all this makes even more sense when you familiarize yourself with the product, but is the distinction between worker and user clear? The reason we went overboard explaining everything is we get questions all the time on how our licensing works, and in 4.x our pricing was based on number of workers, but in 5.x it’s based on number of seats (and seats are based on workers).

Seats

Let’s start by defining a “seat” then we’ll explain why you need to consider seat count when determining your initial financial investment in Cerb. Seats represent the number of workers you can have logged in to the Helpdesk simultaneously. The more seats your company is licensed for, the more workers you can have operating the software concurrently. Once you hit your “seats cap”, the next person who tries to sign on will be locked out until another worker signs out (and lets the session expire). It’s literally the equivalent of giving up your chair for someone else to take a seat.

If you’re an old 4.x user who paid to raise their total worker cap at the time, this cap will be removed when you upgrade. With 5.x you can have however many total workers you want (unlimited), they just can’t all be logged in at once.

You can have as many of these as you want (helpdesk setup, Workers).

Remember, because seats are tied to workers and workers only, they have zero impact on the number of contacts you can have in your Address Book, or the number of Support Center clients you can register — which is exactly why we spent so much time clarifying the differences earlier.

How many seats?

To determine the number of seats you need, just calculate the maximum number of Helpdesk workers you envision working through your busiest stretches. Do you regularly operate with 5 team members during peak business hours? Then go with 5 seats. Have two shifts of employees working round the clock? Take the shift with the larger team and convert those to seats; if you have 15 daytime workers and 10 nighttime workers, you will only technically require 15 seats even though you have 25 workers total.

Installation and license pricing

Configuration-wise there is nothing special required to activate seats. A fresh unlicensed Helpdesk is restricted to ONE seat, but you can sign up for two additional seats free. Once we — WebGroup Media, WGM develops Cerb — send you a license key for a total number of seats (including the two freebies), you simply sign in as an administrator and input the license under ‘helpdesk setup’, ‘System’.

Financially, seats represent the upfront cost of licensing Cerb, once you “buy in” you don’t have to worry about any additional feature restrictions beyond that. All you have to concern yourself with going forward is the possibility you may need more seats at some point. Because the pricing structure is per-seat, should your business grow or your requirements change it’s just a matter of buying more and getting an updated license.

To purchase a license for more than 3 seats visit our website (as of this writing there is a Cerb4 to Cerb5 50% upgrade discount on seats).

IMPORTANT ASIDE: Your purchase technically only covers you for the version you installed, any major releases in the future — 5.1/5.2/5.x — is optional and may require an additional fee. To learn more about “Paid Updates”, check out the buy page on your website (same place I pointed you to for buying seats) or read through our License FAQ.

-joegeck@wgm

Broadcast is a 5.0 feature that carries over pretty much as is into 5.1. As usual the latest up to date documentation will always be on the wiki should this blog post become stale.

http://wiki.cerb5.com/wiki/Broadcast

When you can reply to multiple tickets with a single response you will want to use Broadcast (reply) — Cerb’s answer to mass mailing. Now don’t confuse this with CC’ing a bunch of recipients on an e-mail, broadcast literally appends a copy of your reply to each ticket you selected using bulk update.

Any ticket-based list is compatible, so you can do a search, use a workspace, or pull directly from Workflow or Search Tickets to get your list of tickets. And because broadcast is a part of ‘bulk update’ you can simultaneously move the tickets to a different bucket, set their status to closed, or assign to a specific worker.

Select your tickets, click ‘bulk update’, and look for the “broadcast reply” option.

Personalized Messages

Broadcast was obviously developed so you could avoid writing a unique response to every ticket; one e-mail that you can blast to as many customers as you want. Unfortunately the pitfall with streamlining your replies in such a manner, is you end up dumbing down your “one size fits all” reply into something generic. To counteract this problem the developers have incorporated several different ideas into broadcast to make automated, yet still personalized, replies feasible. However…

Snippets?

Many of the ideas in broadcast are also used in another 5.0 feature called Snippets, and we’re not talking similar ideas, we’re talking identical features. Almost every thing below the “Broadcast Reply” checkbox is replicated inside of snippets (‘mail’, ‘Snippets’ tab). Let me explain with two comparison screenshots.

Here’s a “New Order” broadcast.

And here’s a “New Order” snippet.

So the question is why do they share so many similarities? To understand you need a little background on snippets first. Snippets replaced the ‘E-mail Templates’ of 4.x, with the fundamental change being snippet templates have a new language syntax. This new language allows you to write much more flexible templates that can be used in a variety of situations, and is composed of two parts: contextual tokens and conditional logic. These two components (along with a Test button) are what have been extracted out and integrated separately into broadcast; the three features have also been built into several other features like signatures and auto-responses. We’ll go over each one shortly.

To state the “crossover” in different terms, you can think of broadcast as the distribution tool to deliver a snippet to multiple tickets (ironically at the moment broadcast does not have access to the snippet templates, see CHD-1985).

Where does that leave us? Well the good news is since they share the same interface and language, if you learn one you kind of learn the other in the process. Unfortunately the bad news is this overlap poses a redundancy problem in regards to documentation like you’re reading now. Because you can think of broadcast and snippets as two-sides of the same coin, a lot of their documentation would be identical no matter which feature you’re reading about. Therefore we made a “flip of the coin” decision to keep THIS guide lean, and explain all those overlapping features entirely as part of snippets. In fact the New Order snippet we showed earlier is the snippets walkthrough example.

In conclusion we’re still going to summarize those features here for better continuity, but it’s probably ideal if you read through the entire snippets guide first and come back. If you decide not to, no biggie, going forward there will be plenty of links sprinkled in that point to individual portions of the snippets walkthrough.

• Read about Snippets first?

Tokens

See the “insert at cursor” dropdown below the broadcast reply box? These are optional tokens, or placeholders, you can insert into your message that represent the corresponding fields in the Helpdesk.

Custom fields like *Phone (Worker) are represented by their ID {{worker_custom_18}} inside the reply. The star * was added to the custom field name just to make it stick out in screenshots, it is not necessary.

The token system is something you may have seen in previous versions, but in 5.0 all tokens throughout the Helpdesk are produced through the Snippets system instead. As part of this upgrade the number of token choices have been greatly increased from those found in the worker signatures, auto-responses, and e-mail templates of 4.x. Most, if not all, the fields and custom fields of any mail-related sources (tickets, addresses, organizations, workers) are available to use in broadcast. This gives you a lot of personalized information to insert into your messages with a simple “swap”.

For those who’ve read about snippets already, “broadcast reply” is a ticket context and uses Ticket tokens, “broadcast compose” (more on that later) is a worker context and uses Worker tokens.

• Learn more about tokens and contexts.

Conditional Logic

Ok you’ve got your broadcast “template” written up with a couple of tokens integrated. But what if you have fields without actual values inside of them? What if we never filled in a valid phone number for one of our new employees? What if *Phone (Worker) {{worker_custom_18}} is empty? If it is, you’ll get a blank in every outgoing reply.

As a general rule whenever the corresponding ticket or worker fields do not have data pre-filled, they will translate to a blank phrase. This poses a risk with broadcast because you are potentially e-mail blasting without spot checking each message.

• If you have any questions, please call John Smith at _______ [phone #] or e-mail john@example.com .

To help counter this we’ve implemented some basic conditional logic inside of broadcast (and snippets). This language gives you the option of adding things like if/else statements, which you can use to catch blanks and fix them automatically. If we wanted to foolproof our example we could do something like:

Parts have been simplified or removed for clarity.

Notice how we’ve substituted a “standard” office phone number to safeguard us against a missing phone number. We use an if/else block to check if John’s phone number exists in Cerb, {{worker_custom_18}} = 555-1212, (IF) it does then we print his contact information, (ELSE) if he does not have a phone number in the Helpdesk, we print the main office line.

As far as the “formatting” goes, notice I squeezed all the logic in one continuous line without breaking it up. We could have went with the nicer:

If you have any questions, please call
{% if worker_custom_18 %}
John Smith at {{worker_custom_18}}
{% else %}
sales at 555-4646
{% endif %}

Either way will work, but your final output may have double spacing if you choose to go with line breaks in your “template”. Sometimes it’s better to sacrifice readability in the template so the end result is more professional looking (see “Product Announcements” example at the end).

• Learn more about the conditional logic syntax and other cool things you can modify using “defaults” and “date modifiers”.

Test Button (Preview)

Once you’ve finished constructing your response the Test button will check for any blatant syntax errors first, and then show you a preview of what your message will look like by sampling a Helpdesk ticket at random. All your tokens will be replaced with the ticket’s corresponding field values and any if/else logic will be calculated so the relevant text can be substituted in. Test should give you one last opportunity to eyeball your “template” for any semantics problems; each click samples a new ticket so be sure to do it a few times to test against a variety of scenarios.

Here’s a failed test due to syntax error.

The closing curly brace } is missing at the end of the IF statement: {% if worker_custom_18 % .

Now here’s a successful test and a preview of what a response will look like.

Our example was so simple that it only pulled from a worker object (name, phone number) and not any specific ticket or customer (sender address) fields, therefore it won’t change from ticket to ticket. One click of the ‘Test’ button is enough for us.

• The Test button, similar to a lot of the broadcast options, is also used in snippets, signatures, and auto-responses.

Save as drafts

This is the only option that’s not part of snippets. Select ‘send now’ to queue up your broadcasts for delivery. Broadcast works in conjunction with the Mail Queue service to prioritize your workers’ real-time replies ahead of any queued e-mails. This ensures your Helpdesk does not get bogged down waiting for the last broadcasted message to go out. You can check their progress in the ‘Mail Queue’ tab of ‘helpdesk setup’.

Instead of actually sending your replies immediately with send now you can also save your broadcast-generated messages as individual drafts. This way a manager can review each message, make a couple small changes where necessary, then send them out one by one like normal. Because of how this works, do not use broadcast drafts with the expectation you can stop and pick up your progress later.

• Learn more about the Mail Queue and bulk drafts.

Broadcast Compose

Broadcast isn’t just limited to replies, it also works when you need to create multiple tickets from scratch. You can compose a single message and push it out to a list of contacts — each will generate a separate ticket. The “broadcast compose” procedure is generally the same but you start from an address-based list (address book, recipient history) and not a ticket-based list. Inside bulk update this time around, you will have a (from) group, subject, and ticket status to fill in.

You can also use the tokens and conditional logic inside the subject field, of course all the logic would have to be squished on one line. Because there’s no token dropdown for the subject, just copy and paste the {{token}} after you’ve inserted a temporary copy in the body.

Use Cases

Broadcast is a great feature but sometimes it’s not obvious how to take advantage of it. To wrap this article up, here’s a couple of simple examples that may give you some ideas (often when you see the “template” in its entirety it’s more helpful).

New Orders

This is the one we showed off at the very beginning, and like we mentioned it’s the sample template we created from the ground up as part of the Snippets tutorial. Every syntax detail from the {% if/elseif %} to the {{initial_message_created|date(“m/d/Y”)}} is explained over there should you want to learn more. The “support package” (platinum, gold, silver, and copper) is determined by looking at the subject line of each ticket – New Order: domain (type of package).

Issues Resolved

Businesses in the software field may have users submit bug reports via e-mail. When a new release goes out you can use “broadcast reply” to inform different people about the issues they personally had a vested interest in. Here we assume the bug number and description are in the original ticket’s subject line and that each recipient (initial sender) has a first name registered in the address book.

The three toggles at the bottom are for setting the corresponding “address” custom fields (*Hosted On, *Support Package, *Purchased On). Technically they are a part of bulk update and not broadcast.

Product Announcements

A natural fit for “broadcast compose”, since you’d be the conversation starter sending new messages to each of your contacts (i.e. creating new tickets). Here we’re using some conditional logic to distribute specific upgrade prices to our customers based on date of purchase. We’ve preconfigured a date (address) custom field called *Purchased On {{custom_27}}. To make this easy we’re assuming September 1st is the cutoff date and the discount tiers are structured like this:

• < 3 months -> free upgrade
• < 1 year -> 50% discount
• over a year -> full price upgrade

Unfortunately you have to use epoch time (1275350400) in your conditional logic instead of “english” dates (Jun 1, 2010); I used a Unix time converter to do the number crunching for me.

The “triple spacing” in the preview is a result of the extra spacing we put in the template so it’s more readable for our example. In practice, you may want to squish the template down even if it’s less readable so the final result is more concise. We could have easily removed the line breaks and rolled the if/else statements into the message itself for one giant block of text. As long as you knew what you were doing you could also drop the {# comments #}, which we’ve used here to explain the date math.

Maintenance Updates

Again a perfect opportunity to use “broadcast compose”. To determine which hosted installs are on which hardware we compare a preconfigured picklist custom field (address): *Hosted On {{custom_26}}, where possible values include black, white, red, or yellow. A very simple if/else block automatically sends the correct maintenance window to the right contacts.

-joegeck@wgm

Reports have been revamped for the 5.1 release, this is a preview to tell you about the upcoming feature (as of this writing it is not available for public consumption, but will be very shortly). The latest version of this writeup can be found on the wiki.

http://wiki.cerb5.com/wiki/Reports

If you want more of a quick & dirty “what’s new” go ahead and check out the New in Cerb 5.1 Facebook album first. The photo album covers several 5.1 features, but it also includes a handful of report-specific screenshots and short summaries. That should be enough to give you a taste of what’s in store for the next version. If that’s not enough to satisfy your appetite and you want to get more of a hands-on tutorial, keep reading right here on the blog.

Where are the new reports?

Not to be a downer but let’s get the bad stuff out of the way first… there are no new reports. So before you get your hopes up, there is nothing radically new you can start monitoring in 5.1 that you could not before. Any obscure custom reports (like the following ideas I pulled out of my hat) will not be part of the 5.1 release:

• Time spent completing tasks for an organization
• Average time spent writing a draft

This begs the question, with no new reports how is this an upgrade? While the developers decided not to create fresh reports, they did decide to refine, retool, and revamp all the original reports to simply be better. The couple of big changes we did make will take what you could already track and give you a lot more visual information and tools to play with. Before we get into what’s changed, let’s start by comparing the full report list between 4.x/5.0 and 5.1 reports.

• (blue highlights) Ticket Assignments was renamed to “Current” Ticket Assignments and moved from WORKER REPORTS into TICKET REPORTS. A couple others got similar names but weren’t moved into new sections, like “Currently” Open Tickets by Group.
• (red arrows) Worker Replies By Date has been merged with Worker History. The “Worker History” report name carries over into 5.1 but Worker Replies as-is was dropped.
• And finally the one that probably attracts the most eyeballs immediately, is the extended names of almost a dozen reports (e.g. Created Tickets by Group over Date Range). The “over Date Range” moniker is important for two reasons. First and foremost, it emphasizes the addition of time to the x-axis, a significant upgrade that allows you to monitor trends. Secondly, these are the only reports that got significant makeovers between 5.0 and 5.1; the others (Oldest Open Ticket By Group) typically look the same without any fundament differences. Because of this we will be using one of the over Date Range reports in our example.

Closed Tickets By Group

The best way to showcase the new stuff is to keep up the screenshot comparisons, so I’ll post the equivalent report you would see in 5.0 versus 5.1. (4.x had the same reports as 5.0 with a different color scheme and a bar graph style, but visually they displayed the same data in a similar fashion). A good “go to” example that kind of has a little big of everything is the Closed Tickets by Group report.

Here’s the 5.0 report (pre-over Date range). Pretty plain. You got your date range up top, a couple of horizontal bars for a simple visual, and a table of hard numbers broken down by group and bucket below.

Ok, now here’s the 5.1 version of that report. Notice the immediate difference, the only constant is that date range up top and every thing below it is different. Let’s go over the changes one by one starting at the beginning.

Screens are based off a local test Helpdesk and uses sample data within a very short period of time (days instead of months), just enough hopefully to prove a point. Ideally you’ll get much more “interesting” results on your production Helpdesk.

Filters (Groups)

Hopefully the idea is intuitive enough that it doesn’t need a whole lot of explanation, but the new feature here is you can choose what things you want to filter by and show in your report. What if you want to only compare three of your groups, four of your workers, six organizations, you can do so; in 4.x/5.0 the system would typically compare every group or address book organization, or you could filter only by one worker at a time.

In the “closed tickets” report we have a group filter (by default all groups are part of the chart, even though the group filter initially appears empty); other reports might include a worker or organization filter where applicable. To customize your filters, click the + button.

In this report we get a “group chooser” to make our selections with, but choosers are all over the Helpdesk for when you need to select something out of a list. Try experimenting with links and you’ll see several of these for objects like tickets, tasks, or workers. For now simply select which groups you want to INCLUDE in the report , save changes, and the new additions should appear. Click the ‘Run Report’ button to refresh the page (if you want to remove a group from the filter, click the little blue trash icon next to each group and click ‘Run Report’ a second time).

Unlike previous versions, the reports do not automatically reload when you make changes to the dates or filters. Make sure you click ‘Run Report’ as needed.

Trends & New Charts (Graphs)

This is the biggie since it’s so eye catching. In 4.x and 5.0 we had the simple horizontal bar chart take a total, and then diagram it with no sense of incremental progress (50 tickets closed last week). Unfortunately this missing variable masked the concept of trends over time. In 5.1 we fixed that, and now include incremental progress in the form of a timeline on the x-axis (bar graphs are now vertical to accommodate).

In prior versions it was harder, if not impossible, to monitor any gains or drop-offs in work throughput over significant periods; with the new system it’s very easy to tell if say, we resolved more tickets around this time of year last year than this year. At the top, to the right of the date range, there is a ‘grouping’ dropdown to narrow or expand the timeline into days, months, or years.

We’ve also added five new charts to experiment with — the “stacked” variants layer the data to give you a better sense of proportions.

• Line:
  • 
• Line (Filled):
  • 
• Line (Stacked):
  • 
• Bar:
  • 
• Bar (Stacked):
  • 

Hover your mouse over a colored area and you’ll get a tooltip showing the group.

Worklists

Consistency is the keyword here. 5.1 reports now include the same type of worklists you’ve been seeing everywhere else in the Helpdesk for years. You get all perks of lists, things like (peek), action buttons (close, spam), bulk update, ‘customize’ views, and “copy” to workspace. At best, 4.x/5.0 reports had ticket links you could click and a first wrote address, but there was no way to conveniently manipulate tickets like you can now.

Table Breakdowns

The final new addition at the bottom of the page is a set of tables. These tables are basically text descriptions of what you see in the charts themselves. In the “closed tickets” report, we show the dates and the number of tickets closed that day — if you grouped by months or years you’d see that comparison instead. We also include a grand total (sum) and an average (mean).

-joegeck@wgm

We recognize that the value of what we offer is subjective for each potential buyer.  A company that has been disappointed by a dozen other projects before discovering Cerb5 tends to feel we’re not charging enough; while a company with a low-volume of email — who could just as easily use Gmail for free to accomplish their workflow — tends to feel we’re charging too much.

Like any prudent company, we’ve made several incremental adjustments to our prices over the past 8 years to better harmonize perceived value and project sustainability.  That balance is a moving target.

For perceived value, the project is constantly evolving (e.g. streamlined usability, better performance, and “feature completeness” for a given point in time) which provides a higher return on your investment.  Cerb5 can perform more duties for you than past versions, often replacing less efficient patchwork solutions.  It may even free some of your team members from tedious drudgery (e.g. filtering junk, dispatching, answering the same questions 15 times, or erratically jumping between disparate activities rather than grouping similar work together efficiently) so they can do more billable work.  Our features foster collaboration, and the software encourages your team to cultivate your address book like the asset that it is.  We save you time, money, and sanity.  The degree of that production or savings determines how much you’d be willing to pay.  Our software isn’t a commodity or a status symbol, it’s an investment.  It doesn’t start depreciating the moment you install it.  As you grow, the production or savings scale with you while our prices remain relatively fixed.

For project sustainability, prices may rise a reasonable amount over time as the project becomes more valuable.  Income from upgrades reflects that existing users have a better idea of where the project should be headed than new prospects do; and a healthy project isn’t chasing new prospects at the expense of long-time user feedback.  Our team grows and accumulates experience as we support and build.  With more experience comes more opportunities, and if it became far more lucrative for our team to disband and work on other things then that’s exactly what our best people would do.  Developers, idealistic as we may be, are still capitalists with bills to pay and families to provide for.  Commoditization of software would be bad for everyone.

Our prospective buyers tend to fall into one of four opinions, which are probably similar to the breakdown experienced by other software companies:

1. “I paid less for the last version.”
   These people often received a promotional discount to encourage early adoption, or to help them let go of an end-of-life version.  When Cerb4 first released, it was such a dramatic change from Cerb3 that a lot of people in the community weren’t sure what to make of it.  The first release certainly wasn’t our complete vision, but we also couldn’t afford to spend several years perfecting it without some real-world adoption and feedback.  We encouraged early adopters by offering Cerb3 users an unlimited worker licenses for Cerb4 for about $250.  It was a one-time cost, and it included over three and a half years of free updates as we innovated our way toward the present.  It’s hard to blame anybody for objecting to that deal ending; but it wasn’t sustainable.  That worked out to about $71.42 per year.  At that rate, it takes 700 sales to cover a hypothetical $50,000 salary, and the business model discouraged us from implementing the feedback of existing (free forever) users over prospective (“I’ll buy if you do this and that”) clients.
2. “Your prices are way too cheap and my boss is worried you guys won’t stay in business long enough to push out the next update.”
   “If it’s too good to be true…” These people place a very high value on the project.  They’re accustomed to paying a lot more in exchange for less than what we’re offering, and they want to be reassured that we have a sustainable business model before they go through the effort of switching to Cerb.  While we do occasionally lose a sale for a very large enterprise client because our low price disqualifies us, the fact we’ve been steadily improving the project since January 2002 generally overcomes this objection.
3. “Your prices are way too expensive; there are a hundred other apps out that cost less, and just as many are free.”
   Most people don’t go out of their way to tell us about all their alternatives, they just choose one and we never hear from them again.  If someone sticks around to haggle on price they probably have a good idea of the value of the project.  Either we convince them that the value is worth the price, or they convince us that they need special consideration (i.e. the essence of business).  We offer discounts to educational institutions, registered charities, established open source projects, and cash-strapped small companies.  We’re not the cheapest CRM app — there are many cheaper.  We’re not the simplest CRM app — there are dozens simpler.  We don’t want our primary selling point to be over-simplification.  Our goal is to be working on software that you may need to grow into, but that you won’t grow out of.  Even after working on this project for eight years there are still so many possibilities, and so much more work to be done.  It never fails to surprise us how many other projects think the path to enlightenment is making things ever simpler and simpler.  Technology isn’t getting simpler, it’s just getting better at interfacing with humans.  In nature, the human brain is the most unfathomably complex thing we know to exist; and yet it’s fairly easy to interface with the one you have, and its capacity for improvement is nearly limitless.  The road to the year 2010 is littered with the debris of “simpler” alternatives to the pesky complexity of human thought.
4. “The pricing is fair.  While I’d certainly prefer to get everything I need in life for free, this purchase will pay for itself before long.  The sooner I put it to work the better off I’ll be.”
   This is where we’re aiming.

From a very early point in our project history, we vowed to write software for ourselves — not because we’re special, but for exactly the opposite reason.  Trying to please everyone is a dead-end.  We knew there had to be thousands of other companies out there who shared the same frustrations as us, and wanted the same things we did; even if they didn’t know it yet.  We were more right than we ever imagined.

-Jeff@WGM

Snippets is a 5.0+ feature and this example assumes you are using a 5.0.1 Helpdesk. As of this writing it should be MOSTLY compatible with the upcoming 5.1 release still in development — however I do use “Next Worker” to explain things, which is being replaced in 5.1. Conceptually it’s not super important but it will break the workflow a tad if you try to replicate the example. As always, if you’re reading this post late check for the newest version on the wiki.

http://wiki.cerb5.com/wiki/Snippets

If you find yourself retyping the same responses over and over again, the snippet feature is a great alternative. A snippet is a saved template that can be reused — you can interweave them into your replies with whatever original content you’re writing, however many times you like. Because they are inserted as regular text directly into the text field, this means it’s possible to trim down, flesh out, or clip a snippet together with another snippet inside the response itself, leaving the actual template as is.

Creating Templates

To create and manage your snippets use the dedicated ‘Snippets’ tab inside of ‘mail’; this list will contain all the templates your workers created. Everyone can read or use a template, but only the original author or a Helpdesk administrator can edit it.

We’re going to build off the “New Order” template, select “Ticket” and click ‘Add Snippet’.

There are three contexts: Ticket, Worker, and Plaintext; we’ll go over them shortly.

Tokens

Whatever message you place inside the ‘Content’ field will be saved as a template. See the dropdown and ‘Test’ button? In addition to straight text you can personalize a message by inserting tokens, or placeholders, to be swapped out with any corresponding fields in the Helpdesk.

Selecting one of these tokens places it into your template where it will {{look_like_this}}.

• Current:Worker is of course YOU, the logged in worker, who’s replying and using the snippet. This template will give your customers a contact person in the company should they need to follow-up later.
• Only organizations are given a basic “phone” field, so I’ve created a Worker custom field to give each employee his own number (helpdesk setup->custom fields->worker). You do not need to preface custom fields with a *star, I did that to make custom fields stand out in our screenshots.
• The *Phone (Worker) custom field is represented by an internal ID inside the template as {{worker_worker_custom_18}}. At the moment this is just how it works and something you’ll have to get accustomed to.

Once you’ve got your template reading like you want, the Test button will give you a live data preview by sampling one of the tickets in your Helpdesk, including those that are closed or deleted. This gives you an opportunity to check for any mistakes in your logic (a name should be here not a date) or any syntax errors (deleting a closed curly brace by accident).

Notice in the first screenshot I purposely left out the second “}” in “{{worker_first_name}”.

Even if there’s no errors, because the sampling is random you may get some _______ (blanks) where the real data should be. This can happen if you have a large desk where you haven’t been filling in customer or ticket information regularly; nothing to worry about, just keep clicking the ‘Test’ button to pull in another ticket that’s actually filled in.

I corrected the mistake. My (Joe’s) phone number is pulled from a worker custom field.

For now go ahead and give your template a title (“New Order”) and save changes.

Contexts

Taking a step back. If you recall there were a few types of snippets we could have initially picked from — we chose “Ticket” but there was also a “Worker” and “Plaintext” option. Each one refers to a specific context where the template can be used and consequently dictates what set of tokens you will have at your disposal (in the dropdown).

This is a truncated list but the real one includes much much more. Custom fields like *Support Package (Address) and *Phone (Worker) will appear in the list wherever applicable.

It’s hard to appreciate how the new token system works unless you study it carefully, but notice the cascading effect that gives you access to the deepest fields in the Helpdesk. Most sources have a similar path, jumping from object to object to give you access to the low-level fields; e.g. (initial message->sender->organization->website) gets you a company’s website through the sender’s e-mail address.

Before we get too ahead of ourselves let’s go over the snippet types, or contexts, one by one. Each indented bullet point refers to the actual tokens available.

• Ticket is the most all-encompassing context and includes any data associated with tickets and the e-mails themselves.
  • Ticket: group, bucket, mask, subject, updated …
  • Assignee (Next Worker): e-mail, name, title, organization (address, phone number) …
  • Current Worker (You): e-mail, name, title, organization …
  • Initial/Latest Message: content, created, sender (e-mail, name, organization) …
  • Any Custom Fields that can be tied to the other sources (ticket, worker, address (senders/workers), organization)
• Worker is the next context down so to speak and only includes worker-level fields.
  • Current Worker (You): e-mail, name, title, organization …
  • Any Custom Fields that can be tied to the other sources (worker, address (workers), organization)
• Plaintext is exactly what it sounds like, a barebones context that does not use tokens at all. This is good for generic responses without any personal details.

So the question is why did we choose to split up snippets like this? The answer, contexts force tokens to only show up where they’re relevant.

“Ticket” snippets obviously require a ticket to draw from, this means it only works with replies and NOT with Send Mail or Open Ticket where the ticket hasn’t been formed yet. And while the name doesn’t exactly imply it, “Worker” snippets DO work with replies, Send Mail, and Open Ticket. “Plaintext” being the least strict naturally works with all three as well.

The other reason for creating multiple contexts at this stage may have something to do with planning ahead. Down the road we’ll likely extend templates to other areas of the Helpdesk and the same context problem would exist — tasks wouldn’t necessarily mesh with tickets and we’d probably need to create a dedicated ‘Tasks’ context (‘Plaintext’ will always be the universal piece that works everywhere). The bottom line is the templates in ‘Snippets’ are still limited to just e-mails, but expect that to change later on.

Advanced Conditional Logic

Aside from just tokens, snippets are even more flexible with the new conditional logic the developers added. Thanks to the Twig template language now under the hood, this functionality allows you to meticulously control what your templates say based on any criteria you can come up with. This effectively lets you write very “generic” templates which can be applied in multiple circumstances or customer scenarios.

To explain some of the Twig syntax in detail we’ll extend our “New Order” template, go ahead and re-open it. Let’s assume we have a handful of orders in our Sales group:

• Customers could choose between four packages: Platinum, Gold, Silver, and Copper.
• Each ticket was created using the Simulator plug-in (and “Web Hosting” sample data) therefore they have a predictable subject pattern – New Order: domain (type of package). We’ll capitalize on the fact you can determine the chosen package directly from the subject line.
• You are NOT assigned the tickets; the “next worker” is John Smith.

So here’s the improved template we’re working with.

I’ve intentionally added extra line breaks to make the example easier to follow, but the spacing will affect the actual template. So in practical use you may want to remove any unneeded line breaks to prevent “double spacing”.

The following three Twig conventions are probably all you’ll ever need to work with, but there is documentation should you want to experiment with other syntax (for loops, variables, comments, etc).

DATE MODIFIERS

Your order was received on {{initial_message_created|date(“m/d/Y”)}} …

Every token you insert that represents a date and time will include a default “date” filter (no parentheses), which will output something like July 14, 2010 20:51 . However these tokens can always be modified to display whatever you like in any format you want by defining a (“style”). In our example we chose to go without an actual time of day and only use the typical American month and day “m/d/Y”, but other possibilities include:

• date(“Y-m-d”) :: 2010-07-14
• date(“D M d”) :: Fri Jul 14
• date(“h:m A”) :: 08:51 PM
• date(“h:m P”) :: 08:51 -07:00

Note: There is a pipe “|” character (SHIFT+\) separating the token and date filter, this replaces the ending curly braces around the token name itself.

DEFAULTS

If you have any questions, please call {{assignee_first_name|default(worker_first_name)}} {{assignee_last_name|default(worker_last_name)}} …

If the token you’re using points to an unfilled field you might end up with _______ (blanks) peppered throughout your message, which as we discussed earlier regarding the Test button can be quite common in busy desks with lots of fields or custom fields. To work around this problem you can fallback on a different token or generic text, e.g. “Hi there!”.

In our example “if the ticket is already assigned to a worker (John Smith), print his information, otherwise show my (Joe’s) information”. The idea is whoever is assigned a ticket should have his or her contact information sent back to the customer instead of our own. That way when it gets a little busy at the office, or someone’s on vacation, should another worker need to reply they can do so, letting the customer resume their conversation with the original worker assigned to the ticket. The “default” filter is for handling unassigned tickets where it’s appropriate to include the replying (current) worker’s contact details. John Smith was assigned to all of our new order tickets, so no matter who replies John’s still the team’s salesman.

Note: Just like date there’s a pipe character in front of default; don’t forget to add it yourself because unlike date, “default” isn’t automatically appended to your tokens. Also, if you use a token inside the default(…) filter make sure you remove the double curly braces around the token, default(worker_first_name).

IF/ELSE

{% if ‘Platinum’ in subject %} … {% elseif ‘Gold’ in subject %} … {% endif %}

The sample code sort of speaks for itself, “if A is true then do B, if not check if X is true, if it is do Y”. In our example we know all the possible conditions — each new order fits the same subject pattern and we only have a few preset “packages” to choose from. This makes it easy to look for the appropriate match inside the {{subject}} and determine what level of support people qualify for. If all goes well the corresponding block of text should be dropped into your snippet (“As a ‘Gold’ customer you qualify for…”). As always use the ‘Test’ button to see if you’re getting the expected results with different tickets.

Note: The statements are bookended by {% %}, ‘in’ is a mandatory keyword, and the “endif” is used to close the entire conditional block. Because tokens like {{subject}} are automatically inserted with double curly braces, you do need to remember to delete them from inside the if/else statements.

Using Templates

Once you have created a snippet it’s time to put it to use. Inside every ticket’s reply box there will be a Snippets button to show all your existing templates. Now we are using a “Ticket”-based snippet which means it will work only with replies. As we mentioned earlier, when composing new messages through either Open Ticket or Send Mail you can only use a ‘”Worker” or “Plaintext” snippet.

Click the ‘Snippets’ button to open the “insert snippets” window.

By default the most popular, or frequently used, entries are up top, but you can tweak the sort order or do a quick search to pinpoint a specific template.

(peek) will show you the literal template so you can check if it’s the right one. Even though it may look like it, you can not edit the templates inside the (peek) window; go back to the ‘mail’, ‘Snippets’ tab if you want to make some changes.

Finally, clicking the snippet name will insert a copy of the template with all the token logic replaced. Because we’re working with text and the snippets window stays open until you close it, it’s very easy to include multiple templates wherever you want by continuously moving the text cursor around and clicking a different snippet.

Snippets functionality in other places

Snippets has sort of a double meaning in Cerb5 and it’s worth separating the two concepts for clarity. Snippet Templates is what most users associate the term “snippets” with, and it’s what we’ve been constructing thus far with our new order example. These constructs replaced 4.x’s E-mail Templates; the name change was to emphasize the direction we’re going with more multi-purpose templates.

The other half of “snippets” is the core functionality templates are built on, specifically the contextual tokens and conditional logic from Twig (date modifiers, defaults, if/else). Yes the two “snippet” halves clearly work in tandem, but we need to conceptually distinguish them because these tools have been incorporated into other features. We’ve swapped out the old token system inside signatures and auto-responses and replaced it with the different snippets contexts, plus developed it into the new 5.x feature called Broadcast. Remember you don’t have access to the actual ‘mail’ templates, the auto-responses are now just equipped with “Ticket” tokens and signatures with “Worker” tokens.

What does this mean for you? Well even if you don’t take advantage of the conditional logic, the snippet tokens by themselves offer a lot more fields to play with thanks to the extended reach of contexts. A couple of new things are possible.

More personalized worker signatures

Recall the *Phone (Worker) custom field we created at the beginning to give each employee his own phone number, {{worker_worker_custom_18}} . After you assign them a number inside ‘helpdesk setup’, ‘Workers’, it’s ready for use in your signatures.

Previous versions only included: worker name and title. This is a screenshot of group signatures but the same can be applied to default signatures in ‘Mail Setup’.

Auto-responses targeting specific contacts

The *Support Package (Address) custom field designates a service priority for each sender, {{initial_message_sender_custom_19}} — when a new customer signed up for one of our packages we assigned their e-mail address a status. Gold customers get a special auto-response urging them to call the office should their support ticket go unanswered.

Previous versions only included: date, requester, ticket mask, subject, and body. This is a screenshot of “new ticket” auto-responses but the same can be applied to “close ticket” auto-responses.

Broadcast to multiple tickets at once

Broadcast enables you to reply (or compose new tickets) in bulk with a generic or targeted response. You could for example send out a product announcement that reads the same for everyone, or apply the snippet toolkit to make it more relevant to the intended recipient (“As a recent 4.x customer you qualify for a free 5.x upgrade”). Another good fit for broadcast is processing a batch of new orders like we’ve been doing already.

Unfortunately despite the fact broadcast produces regular e-mail, the templates themselves are not accessible so we can’t use our “New Order” template (see CHD-1985). The best we can do at the moment is copy it from the ‘Snippets’ area beforehand and then paste it directly into the reply box.

I’ve created a ‘Processed’ bucket to archive all the paid orders.

-joegeck@wgm

This post is based off a 5.0.1 Helpdesk and appears to be compatible with the upcoming 5.1 release. The latest documentation we have will be available on the wiki should this become outdated.

http://wiki.cerb5.com/wiki/Explore

The Explorer toolbar is a global navigation frame used for paging through any list in the Helpdesk — i.e. instead of jumping back to the ticket list after each reply, you’d use the explorer to cycle to the next ticket instantly. Explorer doesn’t just work with tickets though, a majority of all the default sections (tasks, organizations) are compatible, plus any filtered searches or saved workspaces; just look for the ‘explore’ link in the blue title bar.

Ticket Explorer

Ticket lists are probably the most common use case, so let’s stick with something simple: replying to your assigned tickets in ‘Overview’. By default explorer starts with the first item on the current page, however you can jump in at any point by selecting (checkmarking) a row beforehand.

Select a ticket and then click ‘explore’.

The paging order is naturally determined by how you’re sorting the list, you can always change the list order by sorting the opposite way or against a different column.

Observe the additional frame now sitting at the top of the page, notice the URL in your web browser is a “unique” explorer link (cerb5/index.php/explore/adf7fcc…/3). That means you could open a second explorer in a new browser window and have two lists going at once, OR you could share your explorer with someone else and they would have access to the same list.

The standard explorer bar.

Even if you browse away from your tickets to another area, explorer will stay active until you deliberately close it; the main benefit being all the navigation buttons still function relative to where you were in the list.

• Cerb logo: Functions as a “home” button of sorts; click it to return to the list you “explored” from. In some cases this will be an approximation of where you left off — instead of the organization’s Mail History tab you get sent back to the default Notes tab.
• Green Title: What you’re browsing; usually this is the same as the worklist name you see at the top of a list. For tickets it could be as simple as the group and bucket.
• URL: A link to what you’re looking at in the Helpdesk; click to open the contents in a new window. Feel free to pass the link to your co-workers for quick access.
• Prev/Next: Page back and forth through the list; the [ and ] keys act as shortcuts.
• X (Exit): Closes the explorer bar.

Note: Ticket Explorer does replace the old page navigation box from previous versions; if you want to use the prev/next links and keyboard shortcuts, you must use the new explorer.

The 4.x version is no more.

Other Examples

The basic explorer generally works the same way no matter what type of list you’re viewing, but a couple of them have some additional options.

Forum Explorer

Activate the explorer from the ‘activity’, ‘Forums’ tab and you should be taken to your linked forums.

Notice the top bar now includes two extra shortcuts, an ‘Assign Worker’ picklist and a ‘Close’ button. Both of these are for manipulating the status of a thread inside the Helpdesk, without leaving the forum itself. After you reply to a thread you can close it out and navigate to the next one; if you return to a closed thread, the ‘Close’ button changes to ‘Re-Open’.

The forums plugin is no longer included with Cerb. To install, download it from SVN into the cerb5/storage/plugins directory, then enable it from ‘helpdesk setup’, ‘Features & Plugins’. (http://svn.webgroupmedia.com/cerb5/trunk/plugins/official/)

Notifications Explorer

Activate the explorer from the ‘home’, ‘Notifications’ tab and you can flip through all the work that needs your attention. In Cerb4 paging was limited to just tickets, but because the explorer can handle multiple contexts (tickets, tasks, forums), paging between them will now work properly.

Browse all your forum and ticket assignments, watchers, sticky notes, comments and task notes.

Unlike clicking into a notification directly, viewing a notification through the explorer does NOT automatically mark it read.

-joegeck@wgm

At the request of the development team it’s time to start a dedicated blog column to promote upcoming features. Appropriately titled Preview! this will straddle the line somewhere between a snapshot of what’s in the pipeline at the moment, and formal documentation ready for training purposes. Once the latest version comes out with the new feature, the most up to date documentation we have will always be on the wiki (I’ll include a link at the top of the post so you can find it). Therefore if you stumble on a post like this a couple months from now and the screenshots don’t quite look the same as your Helpdesk, try the permanent resource instead.

Because we’re still slowly rolling out 5.0-specific documentation, here on the blog I’m going to try and do a bit of a balancing act between old and new; I’ll post completed 5.0+ docs as they become available (Drafts) alongside some of these 5.1+ previews (Links). To tell which is which, article titles prefaced with “New to Cerb5?” will address features currently available, and those prefaced with “Preview!” will advertise features still in development behind the scenes.

Links

Links is an upcoming 5.1+ feature which is not available to download as of this writing. This blog post was written based on a 5.1.0 development Helpdesk. The permanent resource when finished will be here:

http://wiki.cerb5.com/wiki/Links

Previous versions of Cerb lacked the ability to “link” related tickets. Merging tickets was one option but not quite the answer, as that would combine the conversations (messages) and both list of recipients. Another workaround was to copy the ticket masks or URLs into the comments (http://example.com/cerb5/index.php/display/AAA-00000-000), but that wasn’t very practical either; to create “two-way” references you would need to copy ticket A’s mask into ticket B’s comments and vice versa. So here’s where Links comes in to play.

Links enables you to “couple” any two Helpdesk objects together: tickets to tickets, tasks to tasks, tickets to tasks, tasks to tickets, all the main object types can be linked in any combination:

• Addresses*
• Opportunities
• Organizations
• Tasks
• Tickets
• Time Tracking
• Workers

Each relationship is 1:1 so whatever object you link to will include it’s own link back to the source (excluding addresses). This enables you to navigate back and forth without needing to intervene ahead of time, jump from a ticket to a task to another ticket and back again. Every instance of those seven objects (minus addresses) will have a dedicated ‘Links’ tab — a giant list of everything a source connects to.

*Because addresses don’t have their own page with a ‘Links’ tab they cannot link back.

Adding links

Let’s stick with our original problem of linking related tickets. We definitely don’t want to merge them together, what we do want to do is leave each ticket intact as-is and just “bundle” them; this way we can see all related tickets at a glance and jump between them. From your starting ticket, click the ‘Links’ tab and select “add ticket” from the dropdown.

This will bring up the “ticket chooser” window, which allows you to search for specific tickets or groups of tickets and then add them in as links (filter presets?). To make this easy we’re going to do a straight search for tickets with the subject “How long for X hosting?” (samples were created using the Simulator/Web Hosting). Select the tickets and click ‘Add Selected’. Notice you can “trash” any of your selections if you make a mistake.

THE TICKET CHOOSER. To double check these are the right tickets, you can click the subjects to open each in a new tab/window.

When you’re done you will have a brand new worklist with the selected tickets; if we had added tasks or time tracking entries, they would have their own “chooser” and appear in their own distinct lists. These worklists function just like any other worklist in the Helpdesk — if the object supports (peek) it’ll be there, if you can edit the properties from ‘bulk update’ it’ll support that too. The only difference is the inclusion of an “Unlink” button.

Try clicking the linked ticket. That should have jumped you to that ticket’s display page which has it’s own ‘Links’ tab; inside Links you’ll notice the original ticket sitting there. The “two-way” reference I was saying was so important earlier is done for you automatically. Obviously this is substantially better than copying the second ticket’s mask into the comments of the first ticket and vice versa by hand.

Project Management

When problems in the Helpdesk evolve beyond answering support tickets, you can start planning larger projects by getting creative with links. This is a lot simpler than it sounds, and using the word “projects” so loosely is part of what makes it seem more complicated than it really is. The reality is projects don’t technically exist; there is no “project” object (like there is a ticket or task), and there’s no dedicated area where all active projects reside.

What I’m really suggesting when it comes to project management is expanding your use of links to unify several things in one location. There’s no right or wrong approach and you can tackle a new “project” from different angles. Remember each link is 1:1 and if you bind enough objects together you can create a spidering effect, where every related resource is a click or two away. That’s why it doesn’t matter what you start with, although it’s good to pick a decent base as a springboard so you have a starting point later on. Maybe you want to start with a …

• Ticket: Perhaps you get a long-winded e-mail asking for several different things — they need an estimate on upgrading their server, need to speak to billing about a charge on their invoice, and need documentation on your product. Here you’d divvy up all the individual requests into specific tasks, pass those out to workers, and then link them back to the ticket.
• Task: Now let’s assume there’s a planned maintenance update for an aging server, and you’ve scheduled it for the following month. You have a new Helpdesk task to remind you to notify the customers on those servers a couple days prior. What you can do is link the task to each customer’s e-mail address ahead of time, and then when the time comes, send them an e-mail blast (using Broadcast). Even though we don’t have screenshots of the address book, as stated earlier “Addresses” and “Organizations” are one of the seven objects types that are link-enabled.
• Opportunity: You have a couple good sales leads right on the fence, but they all have similar concerns. A couple of the questions are more technical, a couple are sales-oriented, and each was sent to the Helpdesk individually through a couple of different tickets. As a manager you could link the tickets with the same questions together, and pass one set to your sales team and the other to your tech support team (by giving them the “parent” ticket from each). Have each group go through the tickets and leave their responses in a comment or sticky note, when each group signs off, let the manager combine all the responses into the latest ticket and send it out.

My Work

I just got done suggesting you choose a starting point for your projects, but I didn’t really propose a good way to organize them. Again, there’s no “Projects” tab, however there is a ‘My Work’ tab. You can think of ‘My Work’ as a staging ground for personal projects. It’s a new tab we added to the ‘home’ area, where each worker gets their own personal links page to use for whatever they want. Managers may want to use theirs to watch the progress of bigger projects, while workers can use it to keep an eye on what they need to get done for said projects.

The basic idea is still the same, but instead of linking an object to another object (ticket -> ticket), you’re just linking the space itself to an object (My Work -> ticket). When there’s multiple instances of the example scenarios we talked about, we could adapt them to this format — a dozen new tickets with a handful of requests, a couple of tasks where several people need to be e-mailed, and five older sales opportunities that need to be read through — each ‘My Work’ page would have lists of tickets, tasks, and opportunities in one spot for quick access. From there, just click into each project’s “starting point” and you’re all set.

“My Work” the workspace?

If you experimented with workspaces in Cerb4, you’ll recall the default ‘home’ workspace was also labeled ‘My Work’; this should be corrected eventually but for now don’t confuse the two (see CHD-1971).

Naming conventions aside you may be curious what the difference between them is? Doesn’t the screenshot almost look a links page? Why should you do projects with the ‘My Work’ links and not the old “My Work” workspaces? First the similarities.

• Both sit in the ‘home’ menu of each worker and “belong” to each worker to use however they want.
• Both let you view all the different Helpdesk components on one page (tickets, tasks, opportunities, time tracking, …).
• And both let you customize the content of each list.

Now the main difference… With the links tab you are choosing the exact items you want to track, with workspaces you’re filtering the items through a saved search. Throughout this guide we’ve been running a basic search to show the things we want to link to and then selecting them from a list. If you’re familiar with workspaces you know you also do a search, but with workspaces you’re really saving that search so any matches past, present, and future are dynamically selected.

Technically with workspaces you’ve always been able to create simple projects as well, but the point is it’s never going to be as fundamentally sound as the new method with links. To do it the workspaces way, your sources would have to have a common “thread” you could easily pinpoint and find through a saved search. Even the easiest approach is a lot more involved than links.

1. If there wasn’t a keyword or phrase you could use to filter out non-project pieces, you would probably need to create a custom field for each object type you’re using: tickets, tasks, etc.
2. Then set the “Project” custom field to a unique value for each project piece, e.g. “Server Installation”, to include only the results you want and none of the rest.
3. Finally create the workspace and configure or copy a worklist for each type (where “Project = Server Installation”).

None of this is to say you can’t use links in conjunction with workspaces; while distinct concepts there is overlap potential. There’s no reason you can’t link two tickets together, and create a workspace to monitor one or both of the tickets. What I’ve been referring to here is the benefits of constructing a project tab in ‘My Work’ (links) versus a “My Work” (workspace). The former is a practical solution the developers envisioned, the latter was always a bit of a workaround we used to recommend in the past.

More than just a feature

So far we’ve been talking about Links solely as a new notch on your “Cerb5 tool belt”, but the truth is it’s much more than that. Links is part of a larger transition going on in the Helpdesk right now to make room for a completely new infrastructure. In the process the concept has embedded itself into the “core” of the product, and became an integral part of several existing features. Let me explain what I mean with a few examples:

The “Next Worker” (ticket assignment) is gone and in it’s place is “Owners”. Owners are nothing more than worker-links, the assigned workers literally show up as links on the ticket. So instead of “one worker for one ticket”, the new system accommodates “one ticket for one or more linked workers”. Besides manually adding workers/owners from the ‘Links’ tab, you can also add them through the ‘Edit’ button near the top of the ticket; clicking the + button next to ‘Owners’ will pop up a WORKER CHOOSER.

Tasks and time tracking, like tickets, are also deprived of their “worker assignments” and show up as “owners” in their respective ‘Links’ tab. Again, the ‘Edit’ button will work here too.

Time Tracking entries are now directly added as ‘Links’ to the ticket, currently they will not show up as a ticket comment in the ‘Conversation’ tab (see CHD-1983). My name in the small grey text towards the middle, indicates I’m the present owner of the time entry in question.

Time Tracking can now be linked to tasks as well. Similar to tickets each task page will have a “Track Time” button.

There are too many links-related Helpdesk changes to go over in detail so I’ll stop there, but the general idea is some of the old “associations” (like Next Worker) have been migrated into the ‘Links’ tabs. Eventually there will be 5.1 replacements for the “quick start” guides that will assimilate everyone into the new system. But for now we’ll leave this side topic alone…

-joegeck@wgm

Drafts is a 5.0+ feature. This blog post was written based on a 5.0 Helpdesk, so by the time you read this it may be outdated. If what you’re reading here doesn’t match up with a newer version you’re on, check the formal documentation. There’s no promises that will be on latest either, but it will be the only one that’s consistently updated going forward.

http://wiki.cerb5.com/wiki/Drafts

Drafts

Like any good e-mail program our Drafts have two key components:

Continue Later

When you want to resume your progress, or if there was a technical problem like your browser crashed, the ‘Drafts’ tab in the ‘mail’ section will get you where you want to be. This general-purpose tab has a list of all the drafts you’ve been working on in one convenient spot. Click the relevant subject to jump back into the ticket conversation, or send your reply out immediately (see “Send your drafts in bulk” later on).

Click(peek) to review drafts just like regular tickets.

Drafts are clearly marked with a red and yellow tinted ”draft”, similar to the green “sent” and blue “comment” text. Click the ‘resume’ link to get started again (or ‘delete’ if you want to get rid of it). If another worker’s draft is there, you can not modify it.

Failed Deliveries

ALL messages remain in the draft-state until they are successfully sent out; even if you’re trying to send a saved draft from the ticket conversation (resume -> send), it will stay preserved as a draft if there’s a problem. Draft-compatible messages include the standard replies, forwards and compose, but also things like auto-responses and watcher replies.

Send your drafts in bulk

Using the dedicated ‘Drafts’ tab we checked out earlier, workers can “queue up” multiple drafts for immediate dispatch. This can be a good technique if you want to encourage manager reviews on outgoing mail — your staff can save all their messages as drafts, and then have a manager come in later to go through the Drafts tab. With a couple of quickpeeks they can verify each pending reply looks good, then checkmark, ‘bulk update’, and set the ”Do” status to send/queued. (Drafts can be CREATED in bulk too, see Broadcast.)

Be careful not to send unfinished replies!

After you save changes the drafts physically change their status to ”queued” and disappear from the list. These messages are caught in a go-between state and are awaiting to be delivered during the next scheduled ‘Mail Queue’ TASK (helpdesk setup, Scheduler) that will run as part of your advanced cron.

This is what the message will look inside the ticket; while it’s queued you can not edit or delete it from the conversation. But if necessary you can revert it back to a draft from the ‘Mail Queue’ TAB shown below.

Queued?

All queued messages in the system can be viewed by an administrator inside the ‘helpdesk setup’, ‘Mail Queue’ TAB. Over time the cron should slowly attempt to deliver each message — although it can get a little backed up if you sent out a bunch at once. For whatever reason if a message is NOT sent successfully, you can check how many times it failed from here as well.

The queue will stop retrying after 10 consecutive failures.

When multiple messages repeatedly fail, double check your SMTP settings in ‘Mail Setup’. Then inside the ‘Scheduler’ tab manually ‘run (now)’ the Mail Queue TASK to see if the messages are sent this time.

If any of the queued messages died again, it will say so in the output — at that point feel free to visit us in Town Hall or contact us by e-mail, so we can help troubleshoot.

-joegeck@wgm