Body
Purpose
This article explains how Quick Tix are created and managed at BRCC.
Intended Audience
TDX Technicians and TDX Admins
Details
History
BRCC Technology Services recognized the need for technicians to quickly assign themselves tickets or create and immediately close a ticket to record work done. This could have been accomplished using Ticket Templates, but the portal seemed like the cleaner approach. The System Office indicated that they had created "Quix Tix" using an iPaaS flow. This flow assigns the ticket to the Creator and adds it to the Creator's Work.
Admin: Workflow
Ticket Type
The ticket type kicks off all other automation. BRCC is using the System Office category "General"
Automation
An automation exists based on the ticket type to assign a workflow
Workflow
There is a simple workflow created by the System Office that calls "TDX: Quix Tix set responsible PROD". It is just one step connected to Approve.
Admin: Form
For Quick Tix to work, they need their own forms, so technician-only fields that are normally hidden in the portal can be visible. This also allows for hard-coding a service offering. BRCC is being careful to duplicate Service, Service Offering, and Forms almost exactly so that naming conventions carry accross. we are also hard coding the Service and Service Offering on the Form so that reporting is not affected when the QT Service or QT service offering is used.
The form trumps the Portal Service and Portal Service Offering. Here is an example form in edit view and then preview. Note the placement of fields for technician ease of use, and their portal visibility.
Portal
Organization
There was not a good way to hide a Service Offering within a service, so it was clear that Quick Tix needed to be separate. A Quick Tix Category was created, with permissions allowing only authenticated technicians to see it.
Within this category, the services in the rest of the catalog are mimicked, but flattened. There will be less quick tickets than portal Services, so this was done to allow for less clicks.
Inside each mimicked service is the actual service offering. Some only have one, some have multiple, but we have kept the Service Offering classification to keep consistency across all services. To further keep consistency, any "Support" tickets get an order of -1 so they always appear at the top. You'll also notice that BRCC Services have a custom attribute for Service Visibility. This is cosmetic only. The service in this instance is inheriting permissions from the Quick Tix Category, which is restricted to Technology Services.
Description
A Quick Tix template was created to keep track of hard coded fields and give the technician an idea of what they'd be able to do with the ticket. the descriptions are on each Service Offering, and then duplicated on the Service description. There are also links back to the original Service and Service Offering. This is just flat out time consuming but a good framework if these tickets need to be altered later.
Because the ticket buttons move to the bottom of the page while on mobile, the decision was made to also link the title of description to the button itself, allowing for quick ticket creation on the go without scrolling.
TDNext
Here is what a live ticket a technician created for themselves using Quick Tix looks like
These forms are also pinned to TDX in case a technician likes using that view better. BRCC has decided that the best practice for this is to make hard-coded fields read-only. This keeps the ticket classified correctly and provides less of an overwhelming experience for the technician filling out fields.
NOTE: If a quick ticket is submitted within TDX, there is an option for choosing a different "responsible". It is highly recommended to make this field Read-Only. If someone chooses a responsible party other than themselves, iPaaS will change the responsible BACK to the creator.