Tickets

A ticket is a record of a customer's request for assistance or support. When a customer contacts a company with a problem or issue, the company creates a ticket to track the request and ensure that it's addressed in a timely and satisfactory manner. For example, if a user calls in and files a ticket for a problem they're facing any progress would be communicated to them through the ticket.

Tickets are associated with a part (product or service) and can come from both internal and external users. Tickets are also used to communicate progress to the user or other impacted party.

There may be cases where mass communications (broadcast) are necessary in the event of lots of impacted or related parties (such as service status updates). In this scenario, the ticket would be used to broadcast and handle communications among multiple parties, including across multiple workspaces. Broadcast can also be used to engage customers for feedback/ideas (such as new feature ideas). Scoping is important for broadcast tickets as there needs to be a differentiation between broadcast (all revs) vs. multicast (particular revs).

Views of tickets can be found under Support in the DevRev app.

You can export views to CSV or JSON by selecting Actions in the upper-right corner and choosing the format.

Attributes

Tickets have attributes that can be used to filter and group tickets in various views. You can find all the stock attributes listed in Settings > Object customization > Ticket > Stock fields. These are the stock attributes that come with DevRev:

• Owner: The person responsible for the ticket. Tickets are assigned to an engineer, PM, designer, or any other team member through the Owner attribute.
• Group: The group to which the ticket belongs. For more information on groups, see groups.
• Severity: The importance of the ticket. Severity can be set to low, medium, blocker, or high.
• Stage: The current state of the issue. The stage attribute is used to track the progress of the issue through its lifecycle. For more information on stages, see (stages)[#stages].
• Part: The part of the company or product that the issue is related to. For more information on parts, see parts.
• Created by: The user who created the ticket.
• Created date: The date the ticket was created.
• Modified date: The date the ticket was last modified.
• Tags: Tags are used to categorize tickets.
• Customer workspace: The workspace that the ticket pertains to. You can create a new account or workspace if it doesn't exist.
• Target close date: The date by which the issue is expected to be resolved.
• Modified by: The user who last modified the ticket.
• Reported by: Which customer is experiencing the issue. When a ticket is created from an email thread containing multiple customer email IDs, multiple reporters may be added. If a DevRev user adds a new customer while responding from DevRev, or if a new customer responds to the email thread, these new customers are added to the Reported by field. In the case of the Portal, there is only one Reported by, representing the person who has logged in to the portal to report the issue. Additional reporters can be added from the DevRev app.
• Email members: Participants in the ongoing email thread, dependent on the last email. This attribute automatically updates based on the last email sent from or received on DevRev.

Adding members to Email members also adds them to the Reported by field. Removing members from Email members does not remove them from the Reported by field.

Shadow users can also be subscribers and email members.

• CCed members in email: The CCed members in emails will be added to reporters if they are contacts in the workspace to which the ticket belongs. They will be added to email members if they are part of the ongoing email thread, without any workspace restriction.
• Shadow users: Users created for tracking and record-keeping purposes that do not have access to the DevRev app. Shadow users are typically created when Airdrop imports data from external sources and identifies users without an email address. Tools like Airdrop can assign work and attribute comments and actions to them. Airdrop can also create Unassigned users that serve the same purpose but do have emails. Shadow users are considered users (members of the DevRev organization) rather than contacts, although they have no access to the platform. For more information, refer to the import docs.
• Close date: The date the ticket was closed.
• Source channel: The channel through which the ticket was created. Customers can create tickets via email, the portal, and various other channels.
• Channel: Indicates the medium used for customer communication.
• Subscribers: Indicates the group of users who will receive updates about the tickets.
• Needs response: Set to true whenever a new customer message is received on the ticket to ensure that no customer messages are missed. If a particular customer message does not need a response, the Needs response toggle can be turned off by the user. Turning off the Needs response toggle does not affect the SLA metrics.

These attributes can be effectively used in filters and Group conditions across various vistas in DevRev to track specific work, capacity, and more.

You can add custom attributes to tickets to track additional information. For more information on custom attributes, see object customization.

Issues are attached to tickets in order to track efforts with product priorities.

Create a ticket

1. Go to Support > Tickets from the sidebar on the left.

2. Click New Ticket on the top-right corner of your screen.

3. Add a title and description for your new ticket. You can also attach files related to the ticket in the description.

4. Select which part of the company/product this ticket is related to.

   Loading...

5. Enter other attributes for the ticket: change the assignee or accept the default; enter the severity; add any relevant tags to help employees identify any relevant traits of the ticket; select the workspace that the ticket pertains to.

6. If there are other tickets or issues that relate to this ticket, click Link Records and select the relevant items.

7. If you would like to immediately create another ticket, select Create multiple.

8. Click Create.

If a ticket is created from an existing conversation, then the ticket's title and description are populated automatically from the conversation.

You can create a child issue by clicking + Link issue > Add a child issue. You can link the other existing issue as a child issue or create a new one by clicking on + New issue. Just update the title of the child issue and click enter. All other fields will be populated automatically by DevRev. You can edit them later.

Tags

• Stalled
• Priority/Escalated
• Fast/Slow Moving
• Blocked
• Resolution: [value]
• Impact: [value]
• Reason: [value]

Stages

The following figure shows the state machine for tickets.

Open

• Queued (Q) The initial stage for all tickets. When a new ticket is created, it's automatically put into the queued stage, which indicates that it needs to be picked up by a customer experience engineer.

In-progress

• Work in progress (WIP)

  Work on the concern reported by the user has begun. When a customer experience engineer starts work on a ticket, the ticket's stage changes to work in progress. When they require more information, they may ask the customer for additional detail (such as logs or context), in which case the stage would change to awaiting customer response until the customer responds.

  In certain scenarios, the customer experience engineer may be able to resolve the customer's concern. If that's the case, they would ask the customer if their resolution has resolved their concern and the stage would move to the awaiting customer response. Once the concern is resolved and the customer acknowledges the resolution, the stage may move to resolved. If the concern isn't resolved, the stage may change back to work in progress as the customer experience engineer continues to work on it.

• Awaiting product assist (APA)

  The customer experience engineer is waiting for a response or feedback from someone internally. They may need to escalate the ticket to get a response from someone internally. There may be a corresponding issue created to fix the defect, which would transition the stage to awaiting development.

• Awaiting customer response (ACR)

  The customer experience engineer requires more detail or another response from a user. In certain cases where the ticket depends on some fix (issues) the stage may go from in development to awaiting customer response when the corresponding issues have been resolved and the fix needs to be validated with the user.

  In certain cases, the customer experience engineer may be able to solve directly (without any required issues) which may change the stage from work in progress to awaiting customer response to validate they have solved the problem. If either has resolved the customer's concern the stage can move to resolved.

• Awaiting development (AD)

  The issues on which the user's concern relies for resolution are planned but not active, when development on the issue begins the stage transitions to In development.

• In development (ID)

  The issues on which the user's concern relies for resolution are actively being worked on. Once the development process begins, the stage may go from in development to awaiting customer response to validate the fix with the user and then to resolved. If the user wants to cancel the ticket then the stage moves to canceled.

Closed

• Canceled (C)

  The ticket is determined to be invalid either by the user or the customer experience engineer. In certain scenarios, a ticket may have been created by accident and may be canceled by the creator. In other scenarios, garbage tickets may be created through automation or because of spam. Automation or the customer experience engineer can directly close and cancel such tickets.

• Accepted (A)

  The ticket requires a new feature development on the platform for resolution. However, there is no active work on the ticket but the feature addition required to meet the ticket will be done in the future. This stage is added to ensure that feature requests do not linger in the APA queue and to ensure that the right features are prioritized during roadmap planning.

• Resolved (R)

  The goal target stage for tickets. Resolved means that the customer's concerns which led to the ticket have been addressed.

Subtypes

You can create subtypes for tickets to categorize them based on the type of issue. For example, you can create subtypes for bugs, feature requests, or questions. A subtype inherits all the attributes of its parent ticket type. You can add custom attributes to a subtype. To know how to create subtypes and add custom attributes to them, see object customization.

Viewing attachments on tickets

You can view all attachments sent via the ticket's description, internal discussion, or a customer message by going to the Attachments section on the ticket for easy access.

Turing suggests

Turing suggests is designed to aid customer experience engineers in resolving current tickets more efficiently. Each time a ticket is viewed, Turing AI proactively presents a curated selection of similar tickets and related knowledge articles. Additionally, this system includes a feedback mechanism. This allows users to contribute to the continual learning and enhancement of the AI, ensuring an increasingly effective and refined support experience over time. This advancement is a valuable tool in streamlining your support workflow and enhancing overall service quality.

In case you want it to learn and help you better in the future, don’t forget to give "👍" on the suggestion if you like it or "👎" to dislike it.