Auto-Responses

From Cerberus Helpdesk Wiki

Jump to: navigation, search

Auto-responses, or auto-replies if you prefer, are automated e-mails that get sent back to the customer upon receiving a new ticket or closing an existing one. Each group has the option of whether or not to send an auto-reply and can customize the body of the e-mail.

The "E-mail Tokens" are not universal across the Helpdesk, so don't expect things like Worker last name (#last_name#) to be useable for auto-responses. Always check the tokens dropdown for acceptable choices.

Contents

New Ticket

My auto-response as it appears in Apple Mail. Notice the tokens were replaced with actual values.

Incoming mail that successfully enters the Helpdesk and lands in a group with the feature on, will receive an automated response barring a few exceptions. It can't be spam and it must land in a group inbox. This means Inbox Routing rules will stop the trigger if they try to move a ticket to a bucket or another inbox (CHD-1213), making it difficult to reliably bounce a ticket through three or more group and still get the proper one's auto-response.

On the other hand, auto-replies work exactly like you'd expect with Mail Routing because they can only move a ticket from the default incoming group to a second group's inbox (no buckets and no chaining like you get with Inbox Routing). Thus if a ticket moves from the receiving Dispatch group to a Support inbox and both have auto-replies on, the Support group's version will be the only one activated -- you will not get dupes.

Close Ticket

Naturally a closed ticket auto-response is most beneficial when conveying to a customer their issue has been resolved. Now in the oft-chance you want to avoid sending an auto-reply for just a ticket or two, there is a workaround to bypass the triggers. Move the ticket you do NOT want firing to a group not using auto-responses (if you need to, create a temporary one) then close the ticket and wait for the status to change. Afterwards simple move the ticket back to the group it originally belonged to.

I wouldn't recommend a rule like this, it's just to prove a point!

Closing Spam instead of deleting it

The control you have as an administrator (or group manager) over spam management is also contained within the 'Mail Preferences' tab of 'group setup'. You have the option to actually delete or "move to a bucket for review" (quarantine) any possible spam that enters this group, and both choices will restrict new ticket auto-replies from triggering as you would think. However, closing any of this spam will in fact trigger a close ticket response (though deleting will not).

Deleting or quarantining spam mostly negates the auto-response triggers.

Flood Protection

In Cerb4 this mechanism is done by waiting for a preset time threshold to pass before letting an auto-response fire; any reply that triggers during the downtime is dropped and will not be queued up for the future. This is done to prevent potential mail loops where two addresses would be caught in an auto-reply war.

Typically this is not something users have to contend with on a daily basis, and most only run into it when experimenting with their test address before going live. By rapidly sending in new tickets (or closing existing ones in bulk) from an address, the Helpdesk determines that requester is flooding the system and stops delivering replies for each matching message. Ideally in a real world scenario, any spam addresses that flood the Helpdesk will be ignored and your real customers will get their auto-responses.

Limiting or removing the lock

At the same time we realize this can be a practical concern for some Cerb4 companies, who do legitimately get lots of daily support e-mails from clients. If an actual customer happens to send in a series of short e-mails for support inquiries, it's likely they want a "new ticket" auto-response with a ticket mask for referencing each issue. In these cases the flood protection would indeed be acting against your workflow. While there is nothing in the current Cerb4 interface to easily turn down the flood protection timer (CHD-1287), you can make a simple change in the code. The default time between messages is 5 minutes but you can lower that number to less than 300 or simply comment out the entire 'if' block.

cerb5/api/app/Mail.php line 526 (5.1 Helpdesk)

// Make sure we haven't mailed this address an autoreply within 5 minutes
if($first_address->last_autoreply > 0 && $first_address->last_autoreply > time()-300) {
   return;
}

Adapted from a Cerb4 blog post. Note that two of the behaviors have been split into their own wiki articles, while the original Behavior #3 "role reversal" is no longer an issue and has been excluded.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox