Tickets Overview

Summary

This article outlines the basic functionality and options associated with the EngageIP ticketing system. Tickets include various options that allow you to categorize, prioritize, track issues and tasks relevant to your organization, it is also possible to configure actions to fire when tickets are updated, or to create tickets when events occur within EngageIP (creating an account, adding a package, canceling an account, etc.).

You can configure EngageIP to generate tickets automatically if desired, inbound emails to a particular address e.g. support@yourorg.com can trigger the creation of new tickets or update existing tickets. Email updates when tickets are modified are also sent, these emails can be directed to the customer or only to your internal staff based on how you configure email notifications on the ticket and/or who the ticket is assigned to.

Related Articles:

• Ticket Transactions - creates transactions for services rendered which are added to the account on ticket closure

• Ticket Tasks - allows creation of sub tickets so that all tasks or 'sub tickets' are required to be completed before the main ticket can be closed or considered complete

Ticketing System Overview

Assigning Tickets to EngageIP Users

A user's role in EngageIP defines whether or not the user is 'ticket assignable'. If a user is not configured as ticket assignable they will not be listed in the 'assigned to' field on the ticket edit/ add screen.

Ticket Groups, Types, Categories, Sub categories and Resolutions

Groups

Groups are sub organizations of users to which tickets can be assigned. For example, if you have a Support group, and you would like a support ticket to be in the support group pool so that all support personnel can see and process the ticket, you would assign it to the support category. In this case, you would not select an 'Assigned To' user. Groups are assigned by way of Role, for instance a role of 'Support' would be setup and the support dept staff would be assigned to that role. Any users with the role of Support would be emailed ticket updates and would see the ticket in their user ticket list.

Ticket Types

Ticket types is an optional ticket field which defines a particular type of ticket, for instance a trouble ticket. You can create ticket types using whatever scheme you desire, e.g. a basic broad scheme that falls in sync with department names in your organization (support ticket, billing ticket, etc.) or a more granular approach that covers the activities your organization needs to perform (New Order - VoIP, Renewal - Wireless Service, Suspend Service, Port Phone Number, Trouble Ticket, etc.).

Ticket types are configured on the Setup page and can be configured with a 'Sort Order' so that the types you create are listed in a particular order within the 'Ticket Types' drop down list on tickets. You can set a single ticket type with a sort order of zero (0), in order to make it populated by default in the Ticket Type field on tickets.

Ticket transitions can also be added to ticket types in order to define the statuses a ticket can transition to as well as who is assigned the ticket when it is changed to a particular status. For example a ticket type of 'New Service Order' could exist with transitions configured, the transitions may permit the ticket type go from Open status, to Provisioned status, to Scheduled, to Installed, to Active and finally to a Completed/Billed status. The group (department/team) assigned to the ticket can automatically change based on your transition configuration as well, for instance the New Service Order ticket is created by Sales, then as the status of the ticket changes it gets assigned to Provisioning, Scheduling, Integrations and finally Billing.

Categories

Categories allow you to group similar issues. For example, any ticket considered an authentication problem may be assigned to a category of 'Authentication Issue'. This allows you to better define tickets within the groups and to report on the types of tickets overall and within groups. This option allows you to categorize your roles into groups from which tickets can be assigned. All individuals assigned to the roles within the specified group will be able to view any tickets assigned to the group prior to it being assigned to a specific individual.

Sub Categories

Sub categories are an optional ticket item which can be configured under the categories that you have setup. Sub categories are useful if you have many options in your category list and need to further organize category options for better ticket management and reporting. For instance your categories may cover general activities (billing inquiry, support request, sales inquiry, etc.) with sub categories that provide specific detail (cancelation request, degraded service issue, package upgrade, etc.).

Ticket Resolutions

Ticket Resolutions are attached to categories and sub categories so you can define particular resolutions per category / sub category. E.g. a category called 'Billing Inquiry' could have ticket resolutions such as: 'Answered customer inquiry', 'Issued credit', 'Processed payment', 'Reactivated Service', etc.

Ticket resolutions are configured under the Setup page / Ticket Categories.

Hiding Sensitive Information

If there is internal information that should be logged in the ticket but viewable only by internal staff there is an option to hide a comment from the 'related to' user. This is called 'Hide Comment From Related To' (which is enabled by default).

This option will hide the comment in the ticket for the related to user (the account which the ticket is opened on). i.e. if the ticket is opened under 'user1' and user1 has access to log into the AdminPortal / a customer portal to view the ticket, the comment will not be displayed under the 'Ticket History' section. If another user with the proper role permissions logs in (agent/admin) they will see the comment as (Hidden) under the 'Ticket History' section.

Users with the proper role permissions who are not the 'related to' user in question can click on 'Hide from related to' or 'Unhide from related to' as needed to make the comment visible to the related to user/account.

Options for Emailing Involved Parties

There are check boxes on the tickets screen that toggle the email capability for emailing the user (related to), the admin (assigned to) and the category (or group of users). Checking any or all will copy an email on the update of the ticket to the respective users. This allows you to specifically email a party. Optionally, to email without actually updating the ticket, there is a button to just 'Email related to'. See the Situations in Which Admins or Customers Will Receive Ticket Notifications section below for info on who gets emailed and when.

Attaching Files

This allows you to upload and attach any sort of file, zip, exe, .jpg, etc. Any type of file may be uploaded and stays on the server and linked to from that ticket. You can also delete attachments as required. The attachment is linked to the ticket so that it follows the ticket to whomever the ticket is assigned. An icon beside the attachments provide the ability to delete while clicking on the link allows you to view or download the attachment. If the file is an image, it will display in the interface, otherwise it will prompt to download the file. The tickets list now has a column to detail which tickets have attachments on them.

Ticket History

The ticket history is always listed below the ticket in ascending chronological order (latest updates appear at the bottom of the screen). Within the history are the attachments associated with the detail in the ticket at time of upload.

Escalation Rules

These are rules that can be applied to tickets based on ticket priority, or length of time open etc. which will escalate or send a ticket to another user account. This ensures that action is taken if a ticket has not been resolved. Escalation can be based on a single priority or a combination of priority, time open, role and such. Any ticket matching said criteria will be moved in EngageIP to the configured priority and category so that someone else has the chance to review it and update or move it as required. There is an option on ticket escalations to show or hide the log of the escalation rule running. For example, when a ticket is escalated, the logic for the rule adds a comment to the ticket showing what it did, escalate it or change assigned to for example, this is the comment that you can toggle on and off in terms of what the customer sees in a customer portal or in emails. For configuration instructions see the Setting up Ticket Escalation Rules article.

Automated Email to Ticket Conversion

Automated email conversion allows the configuration of email servers and email accounts from which to draw emails from and convert them to tickets assigned to the appropriate categories. The system will login to for example support@support.com account, download the email, and convert that all to tickets in the system. Any email received will be assigned immediately to the ticket category and account listed in the configuration with the appropriate priority settings. Multiple email accounts can be configured and forwarded. For example, you may configure a general support email so that they would be forwarded to a general support pool. Another email account may be for a billing issue, it can be forwarded to a billing group of admins and so on. This logic is detailed in the Email To Ticket Functionality and configuration section.

Ticket Reports

The Ticket report consists of a list of tickets with ticket ID, subject, Owner name, account name, 'Assigned To' and all the categories and groups and identifiers that are involved with tickets. This report can be summarized and sorted based on the view configured to narrow the data in the report down to what you need to see, or print out.

Ticket Page

The tickets page in EngageIP will always be related to the user account you are on (the account you are currently on is shown in the bread crumb trail). If you are logged in as admin for example, looking at the tickets page on the admin account will show tickets assigned to admin, tickets in groups to which the 'admin' role is related and tickets created on the Admin account specifically (i.e. someone clicked the tickets page on the admin user and clicked Add to create a new ticket on that account).

As it relates to owners, the top owner 'LogiSense Corporation' will see all tickets in the system, including branded owners tickets underneath. Branded owners will see only their tickets and those below on branded or unbranded owners. Users (parents and child accounts) will continue to only see their direct tickets.

It's important to understand which roles are assigned to which groups in EngageIP so that you know why or why not a particular ticket is visible or not visible on an accounts ticket list.

Open

The key questions are:

• Who are you logged in as?

• Which account are you currently on?

• Is the 'assigned to' configured on the ticket - if so, the assigned to user should see the ticket in their list

• Is the group dropdown populated on the ticket - if the group is not populated, the ticket will only be visible under the account that it was created on or to the 'assigned to' user if selected

Viewing All Tickets

To view all tickets in the system regardless of group, 'assigned to' setting or otherwise, the best option is to use the tickets report.

1. Go to an owner account

2. Click Reports

3. On the Owner Reports side (right hand list), click 'Tickets'

Open

Ticket Emailing Capabilities

Within the ticket system is the functionality to forward emails to various contact points associated with the ticket. Admins for example will get updates on tickets they create and there are check box options to forward an email update to a customer for example when the ticket has been updated. The scenarios where emails are sent out are listed below.

Functionality:

• The user that creates a ticket (admin or customer) will always receive an update whether they update it, or the person who it is assigned to updates it

  • This will also occur for a customer who creates a ticket in a customer portal. They will receive an email on creation and for updates (the email the customer receives will not include hidden comments)

  • When 'Email Related To' is checked, the user on the account that the ticket is related to will receive an email of the ticket at the email address configured on the account contact page

  • The 'email related to' button simply emails the 'related to' user once without the person looking at the ticket having to add a comment and click save (hidden comments are not sent to 'related to' or 'related other' users)

• When a user assigns a ticket to another user, the user to whom it has been assigned will receive a ticket update notification

  • When 'Email Assigned To' is checked, the user present in the assigned to field will receive an email (defaulted to on, hidden comments will be included)

  • When a ticket is assigned to a group, each member in the ticket group will receive an email notification of the ticket (hidden comments will be included) (this requires that 'Email Group' is checked)

  • If the admin user has clicked 'Watch This Ticket', they will see the ticket in their tickets page, they will also receive email notifications on ticket updates

• When admin creates a ticket and assigns it to another user, admin will not receive an email, assigned to receives email

• When ticket is updated by an admin user, 'assigned to' user is emailed, admin user is not emailed

• When 'Assigned To' updates ticket, nobody is emailed (this assumes the 'assigned to' user doesn't change who the ticket is assigned to, for example, he leaves the ticket assigned to himself)

• When a ticket is assigned to a group, nobody is emailed

• When ticket is edited by member of the group, the admin user gets an email, if admin updates it, no members of the group get emailed

• Emails sent to the customer will include the ticket number automatically

  • No tokens need to be used in this case. A general description telling the customer that a ticket has been opened will suffice. Links to logos and formatting are acceptable as well

• Emails sent from EngageIP to users, admins or customers, will be sent to the email address on their contact type that is marked (from the setup page/contact types) as 'Email Contact'

Branded Owner Email for Ticket Groups Configuration

What can be done to support the emailing of groups with branded owners is to create 1 role on the branded owner (on each branded owner as needed) for each ticket group which needs to receive email. Next, add a 'placeholder' account with each of the associated roles on which exists the email/s you wish to have tickets send to when 'email group' is selected. This can be an alias (one address for several people configured on your mail server) or each email address added to the user as needed.

Steps:

1. Create a role for each ticket group on each branded owner to which you need ticket groups emailed from associated that role to the specific ticket groups (same as top owner)

2. Add a placeholder account on each branded owner for each of the roles created for the associated ticket groups

3. Add email addresses or a single alias on the placeholder accounts to allow emailing to that group the tickets from which 'email group' was checked.

Testing:
Test the configuration by going to a ticket on a branded owner, click email group, and ensure all recipients received an email related to that ticket (event log will confirm which email addresses were sent to)

Situations In Which Admins or Customers Will Receive Ticket Notifications

The above configuration of 'Contact Types' on the setup page play a key role in who is emailed on ticket updates, and to which email those updates go. The two columns specifically are 'Email Contact' and 'Receive Tickets'

• Email Contact - if YES, any bulk emailing or invoice emailing will use this contact and any emails on it to send invoices or canned emails to.

• Receive Tickets - if YES, any emails sent through tickets, (by clicking 'Email Related To', or 'Email Assigned To', or 'Email Group' ) will be sent to email addresses on contacts marked as 'Receive Tickets'. Emails from tickets will NOT go to any contacts marked as 'Email Contact' unless they are also marked as 'Receive Tickets'

The combination of the above, if email addresses exist, could me that emails will be sent to those contact types and any associated emails. In the example above, the technical contact would receive ticket email updates but would not receive an invoice manually emailed to the account, whereas the billing contact would receive the invoice manually emailed as well as ticket updates since for the billing contact both columns are checked as YES.

Admin will receive an email from a ticket if: (admins will ALWAYS receive ticket emails with 'Hidden' comments regardless of configuration. Admins are users in the system that are NOT the 'related to' user)

• the ticket was created by them

• the ticket is assigned to them and 'Email Assigned To' is checked

• the admin user is in a ticket group to which the ticket is assigned and the 'Email Group' is checked

• they are the account to which new tickets are opened using the 'Email To Ticket' functionality (Note: When only Ticket Group is specified and NO user is specified, an email is NOT sent to the group members in this case)

Customers will receive an email from a ticket if: (Customers will NEVER receive individual comments that are marked as 'Hidden')

• they created the ticket originally and the comment is not marked as 'hidden' and the ticket is not subsequently marked as 'hidden'

• an admin updates a ticket and checks 'email assigned to' and their contact was one of the ones in the 'selected' column or their email address was in 'related other' text box

• they are in a ticket group to which a ticket is assigned and the 'email group' check box was checked

• they had emailed originally and the 'Email to Ticket' automatic reply was sent to them notifying them that a ticket was created

• 'related other' has emails in it, 'related other' addresses will NEVER receive individual comments marked as 'hidden'. 'Related Other' is considered the same sort of contact as 'Related To'

Group Users will receive an email from a ticket if: (Group users will ALWAYS receive comments that are marked as hidden, as group users are considered the same as general admin users)

• a ticket was created and assigned to that users group (as assigned on role) and 'email group' was checked

Comments

Comments below the main ticket window represent the complete history of the ticket, they show which are hidden and which are not (hidden comments are hidden ONLY from the 'related to' user). In addition, after the fact of adding a comment you can delete or hide or unhide that comment. The options for that show PER comment as illustrated below.

Email Ticket Scenarios

Below you'll find a number of images demonstrating some common scenarios and combinations of contact check boxes.

Scenario A - Based on the options selected in the image, this ticket will:

• email the group assigned if one was selected (the example has none currently). So any users associated with that group by way of roles will be emailed a copy of the update

• email the 'Assigned To' user, in this case 'admin'

Note: the comment will not be hidden from the customer because the 'hide comment' was not selected. In this case the user could log into a customer portal and see these latest comments. The fact that 'Jim' is in the selected field will do nothing since 'Email Related To' is not checked.

Scenario B - Based on the options selected in the image, this ticket will:

• Email the 'assigned to' user - 'admin' in this case

• Hide the comment from the user / customer

Scenario C - Based on the options selected in the image, this ticket will:

• Email the 'Selected' Jim Smith contact - because 'Email Related To' is checked

• Email the 'related other' contact - because 'Email Related To' is checked

Scenario D - Based on the options selected in the image, this ticket will:

• Email the 'assigned to' user

• Email 'Jim Smith' as he is in the selected box - because 'Email Related To' is checked

• Email Harry as he is in the 'related other' box - because 'Email Related To' is checked

The comment is not hidden, the group is not emails (if a group was selected)

Ticket Button Definitions

The above buttons will be generally available (depending on role permissions, and how the ticket was originally created) on the top of the ticket edit screen.

• Email Related To - this will quickly send out the content of the ticket to the related to email addresses without the need to enter another comment or do anything else on the ticket. Only the visible comments will be sent to the related to email addresses

• Hide This Ticket - this will also show as 'Unhide this ticket' if ticket is already hidden. It allows you to switch the whole ticket from hidden to unhidden and back. Hidden means customer won't see this ticket in a customer portal. As well if hidden, it will remove the check box called 'email related to' to prevent you from accidentally emailing the 'related to' emails. NOTE: If the ticket was created by the end customer, the option to HIDE the ticket will not be available. To have a hidden ticket, you can create a ticket task or a new ticket accordingly

• Workorder - clicking this allows you to assign this ticket to a workorder

• Print - this opens a new browser or tab with a printer friendly version of the ticket for printing to a local or network printer

Email to Ticket Functionality and Configuration

EngageIP can be configured to check an email inbox and create tickets from incoming emails. Tickets can also be updated where the subject includes the existing ticket number in a specific format (i.e. 'Ticket #12345')

Once email to ticket functionality is configured EngageIP will read inbound mail from the configured mailbox and check to see if the subject line contains a ticket number. If a valid ticket number is NOT present on the subject line EngageIP will look up the senders email address, attempt to match it to an account in EngageIP and if found, it will create a ticket under the user account and add the text of the email and any attachments to the ticket. However, if the senders email address is found on multiple accounts a ticket will NOT be created and an error will be written to the event log.

If both a ticket number is NOT present in the email subject line and the senders email is NOT found in EngageIP, then the email will be directed to a fall back email address to notify people in your organization of an incoming support request that EngageIP could not process. See the 'FallBack Configuration' section below for more information.

Ticket Creation/Updates Email Notifications

If the Subject Line Does not Contains a Ticket Number

If the conditions described in the Functionality Overview section above are met, a ticket will be created and the following parties will be notified:

• 'Ticket Group' members (if specified on the ticket) do NOT get an email when a new ticket comes in. The ticket is simply assigned to that group and would show up in their ticket lists

• If a User is specified (in the Incoming Email Account Setup) the specified user will receive an email regarding the opening of a new ticket

• The sender will receive an email notice that a new ticket has been opened

• CC'd addresses on the email will receive an email notice that a new ticket has been opened

• Addresses in the "To:" field of the email will not receive notification that a new ticket has been opened
  
  

If the Subject Line Contains a Ticket Number

If ticket number is present - EngageIP will look up the ticket and append the detail of the email to the existing ticket and any attachments existing on the email, if one or more of the following conditions are met:

• the email address is on a contact that is marked as the email contact on the ticket under 'related to'

• the email address is on a contact that is marked as the email contact on an account that is in the ticket group (associated to ticket group via roles)

• the email address is on a contact that is marked as an email contact attached to an account that is defined as the 'assigned to' user

• the email address is listed in the 'related other' section of the ticket

• the email address is on a contact that is marked as email contact on an account that is listed in the 'selected' box on the ticket

• the email address is setup on the 'assigned to' user

In this 'Existing Ticket' scenario email notification works as follows once a condition is met:

• The 'Assigned To' user will receive an email with the ticket update details

• If a User is specified (in the Incoming Email Account Setup) the specified user will receive an email regarding the email

Configuration

1. On the Setup page click Incoming E-mail Servers

2. Configure the account, categories, and other option defaults

3. Select a canned email from the list so that customers will receive an email notifying them that the ticket was created

4. Configure the forwarding address - this is the email that EngageIP will forward the email to if it cannot find a match for a customer in the database. Do not set this to the email address that you are checking otherwise an endless loop of emailing and checking will occur

5. To test, send an email to your 'support' address

6. Ensure that the Event Manger is running

7. Check the ticket to confirm that it was created / updated

EngageIP looks for the following tags to determine where to cut off the email:

• "wrote:"

• "from:"

Incoming Email Account Setup:

An email may look like the canned message below with a note that a ticket was created on the their behalf.

Example Canned Message Format:

FallBack Configuration

In the event that a customer email does not exist in the system, normally the system will simply forward that incoming email to a designated fall back address, which is the 'Forward Identity Email Address' in the incoming mail server setup above. If you then want to generate a generic ticket from that email as a fallback measure, you need to setup a secondary incoming email server. The logic goes like this:

1. Customer emails in

2. System cannot find an email address related to an account (or too many emails exist in your system from that person and it doesn't know where to add a ticket)

3. The system will forward that via the 'Forward Identity Email Address'

4. Setup a second incoming mail server to check the mailbox for that forward identity email address.

5. Since the email is forwarded from EngageIP, the FROM address will be your support email address. If that support email address exists on a generic account in the system, the system then can take that email and generate a ticket under that generic support account

6. Then you can associate that ticket as needed to other accounts (if you have the custom code installed to switch the 'related to' user)

The end goal is that if the system can't find a user, it forwards it to your secondary incoming mail server which then is able to associate and generate a ticket on a general support account you've setup.

Ticket Groups

Ticket groups allow the pooling of tickets within groups that can be seen by multiple admin users. If a ticket is created with a group assigned, all members of the group will see the ticket in their lists. If 'assigned to' is left blank, that will be a flag to admin users that a ticket has not been assigned and anyone that sees it in their ticket list can pick it up, assign it to themselves and work on it.

If a ticket group is configured on the 'Email To Ticket' configuration page, group members do NOT get an email when a new ticket comes in, it is only assigned to that group and would show in their ticket list.

Configuration Items

Admin users are assigned to groups by way of Role. Click on Ticket Groups on the setup page, then click on an specific group you created and you'll see a series of check boxes below pertaining to roles. 1 or more roles can be attached, those are the roles (and users within which) will see the ticket in their ticket list.

Functionality

When ticket groups are setup, any user logging in with a role attached to the ticket group, will on their ticket lists, see tickets related to that group. If you're working on a ticket and you wish to email all members of a group, you can click 'Email Group', it will send an email to all users within the roles that are attached to the ticket groups.

Ticket Watching

As an admin user that has not created the ticket, you have the option to 'Watch This Ticket' (a button along the top of an existing ticket). This allows you to keep track of the ticket.

You will:

• See this ticket in your list until you click 'Stop watching this ticket'

• Receive emails whenever the ticket is updated

Ticket Import of Base Configuration

The below xml will import a base set of preconfigured categories and sub categories which can be tweaked for use as needed

Troubleshooting

Emails Are Not Being Sent

• Ensure the 'EngageIP Event Manager' service is running on the server, the Event Manager Service handles the following functions:

  • Sends emails related to this functionality or other system emails

  • Executes ticket escalation functions

  • Executes workflows on timers

• Check the top level owner event log for errors, branded owners may not have full detail in their event log when troubleshooting email errors

Inbound Emails Do Not Update the Ticket

• Make sure the subject contains the matching ticket number somewhere in them subject line in the proper format (i.e. "Ticket #xxxxxx" where xxxxxx is the ticket number). If EngageIP sees this string, it will append the email to the ticket with that number

• Review the functionality and configuration sections outlined in the Email to Ticket Functionality and Configuration section to ensure the configuration is in order and the inbound email address meets the proper criteria