46865882c6
PSA abstraction layer with provider pattern, ConnectWise integration (connection management, ticket linking, note posting, status updates, member mapping), Integrations page UI, Fernet credential encryption, in-memory TTL cache, 6 DB migrations, ConnectWise API reference docs.
48 lines
3.5 KiB
Markdown
48 lines
3.5 KiB
Markdown
1. Last updated
|
||
|
||
Mar 31, 2023
|
||
|
||
2. [Save as PDF](https://developer.connectwise.com/@api/deki/pages/1258/pdf/PSA%2bService%2bTickets.pdf "Export page as a PDF")
|
||
|
||
## Overview
|
||
|
||
Anything that is an actionable item should become a ticket. Today, the natural course of business is to send tasks and get things done via email. If you want to stick with email, you can send the email in to create a service ticket on the service board.
|
||
|
||
## Service Tickets
|
||
|
||
|Tickets are crucial to the success of any ConnectWise PSA integration. There are many different types of tickets and reasons for creating them:
|
||
|---|
|
||
1. Anything that requires work that you would spend time on
|
||
2. Alert
|
||
3. Portal request
|
||
4. Client question
|
||
5. Client request
|
||
6. Voicemail
|
||
7. Email
|
||
8. Internal request
|
||
When everything is a ticket, you are creating that accountability loop to ensure that tasks get completed. Keep in mind that tickets are the building blocks for projects, and they can be imported into a project.
|
||
> Want to learn more? Watch the <u><a href="https://www.youtube.com/watch?v=5TQU5scQ8eA" rel="external nofollow" target="_blank" title="https://www.youtube.com/watch?v=5TQU5scQ8eA">Everything is a Ticket</a></u> video.|
|
||
|
||
## Business Case
|
||
|
||
|When it comes to ConnectWise, all roads lead to Rome. This concept means all things should be in ConnectWise. As an integrator, the pathway to mutual success is creating tickets. Tickets can come from:
|
||
|---|
|
||
1. Calls
|
||
2. Emails
|
||
3. Alerts
|
||
4. Issues
|
||
There are many intricacies with service tickets and the available fields that can be used to categorize, classify and add to the existing workflows of our mutual partners. From the figures provided, you can see that there are a large number of fields available for creating a tight integration experience.|
|
||
|
||
## Fields
|
||
|
||
|When it comes to actually creating and updating tickets there are many fields that can be utilized in order to create the best integration experience for the mutual partner.
|
||
|---|
|
||
When you are going through the initial integration setup, it is a good idea to map to as many of recommended fields as possible. A baseline integration is simply going to update a summary line and select a single service board.
|
||
A best-in-class integration is going to be able to take all or most of the recommended fields and be able to build upon those in order to ensure that the integration is compatible with each partner's workflow.|**Summary** \- The subject line or description line for the ticket.
|
||
**Board** \- The service board determines which team will be working on the service ticket after creation. This also helps to determine billing options.
|
||
**Status** \- Statuses should be changed as the work for the service ticket progresses. Statuses are defined in the Status Tab of the Service Board setup table
|
||
**Type** \- The type of service you are performing for this service ticket. Service types are defined in the Types Tab of the Service Board setup table.
|
||
**Subtype** \- Subtypes are used to provide further detail to your main service type.
|
||
**Item** \- Items are used to provide even further detail to your main service types and subtypes. Partners can use items to set up automated task additions to tickets as they are created based on service templates.
|
||
**Priority** \- The impact and urgency are defined as a singular value to determine the priority of a ticket. Typically defined by a color.
|
||
**Source** \- Where the ticket originated. This is usually something such as Email Connector, Phone, or from Integration.| |