Apps
The Support and Build apps on the DevRev platform enable customers (rev users) to coordinate with the product or service builders (dev org) and the different parts of the dev org to coordinate with each other.
Conversation → Ticket → Issue → Task
In this flow, context is preserved. Between every integration hop and side conversation, important details that help define the ‘why’ behind work is lost. That context defines the problem and requirements for anyone that works on this issue.
Both tickets and issues are always associated with rev parts.
Convergence: Bringing Work Together from DevRev.
The following figure shows a high-level view of the relationship between revenue-generating and product-delivery work.
DevRev has a capability called PLuG that enables companies to embed a conversations widget within their applications. Once PLuG has been enabled, all customer conversations can be tracked within DevRev and any Conversations can be immediately linked to a ticket, a ticket to an issue and subsequently to a part (product capabilities and features).
| Link | Control |
|---|---|
| Conversation → Ticket | Open the conversation and click Tickets > + Link tickets. Either create a new ticket or select an existing ticket. |
| Ticket → Ticket | Open the ticket and click Tickets > + Link tickets. Either create a new ticket or select an existing ticket. |
| Ticket → Issue | Open the ticket and click Issues > + Link issues. Either create a new issue or select an existing issue. |
| Issue → Ticket | Open the issue and click Tickets > + Link tickets. Either create a new ticket or select an existing ticket. |
| Issue → Issue | Open the issue and click Issues > + Link issues. Either create a new issue or select an existing issue. |
| Conversation | Ticket | Issue |
|---|---|---|
 |  |  |
To delete a ticket or issue, select the work item in list view and click the Delete icon in the task bar that appears.
Conversations
Conversations refer to the communication chains you have with your rev users. They begin in the DevRev PLuG widget, which enables live chat within customers' apps with just a few lines of code. Unlike most platforms, customer conversations are no longer siloed to just support, sales, and customer success staff. Instead, they are accessible to everyone in the dev org through the PLuG inbox. The service-level metric for a conversation is time to response.
Example: "I have a problem with product X."
You can add a title to your conversations as well as members from your own dev org and other members from the user's rev org without starting a new thread or email chain. Because there can be many tickets attached to a single conversation, there is no need to start a new thread for new topics either.
We recommend closing the conversation whenever you feel the interaction has reached a natural end. Closing the conversation will not close the tickets and your rev users will still be able to see them in the widget.
Tickets
A conversation is typically started by rev user. It may be a short interaction, such as a quick question about a sale, that does not require a ticket. If a conversation takes more than 5 mins to close, we recommend that you open one or more tickets. A conversation could also contain one or more items that you would want to capture in a ticket. A ticket is used to capture anything that you may need to follow up on from a conversation, which could be bugs, feature requests, or anything in between. A ticket is associated with a part of the product and can come from either an internal or an external user.
Example: "User reported a problem using product X. They need a workaround for this problem."
When a support ticket is filed, it is a commitment that the concern will be addressed or resolved. The service-level metric for tickets is time to resolution.
You might have seen systems (such as Intercom) that have just conversations or systems (such as Zendesk) that just have tickets. Although a lot of customer problems can just be solved with a conversation, some of them do require more work. Those workflows of solving a customer problem are much better represented in the ticket where customer-facing and product-delivery teams collaborate.
For example, if a rev user wrote in and reported a crashing behavior, asked for an enhancement to an existing feature, and asked for entirely new functionality, you would likely create three tickets all linked to the same conversation. This means you do not need to ask your rev users to write in separately about each topic they'd like to discuss, while the dev org can still track each item separately.
In the DevRev app, a support engineer can create a ticket based on a conversation they had with someone using the PLuG widget. This ticket and conversation are linked.
A ticket should describe what the rev user is experiencing in language that is familiar to them. Developer-specific language will be reflected in issues.
Issues
Later on, a software engineer may start work on this ticket by creating an issue and breaking that issue into smaller pieces with tasks. An issue describes what the developer will work on and is created or accepted by someone who owns or works on the associated part of the product. This distinction allows developers to break up a ticket from a rev user into issues as they see fit and delegate the work to other team members as necessary.
Example: "Feature A on product Y exhibited unexpected behavior. This is a defect and needs to be fixed."
Tickets and issues are linked in many-to-many relationships. It may require multiple issues to resolve a ticket, or one issue may resolve multiple tickets if different rev users experience and describe the same behavior in different ways.
Work state relationships
The following figure shows how the stages between various work object types relate:
Vistas
In DevRev, a vista is a list of objects (such as tickets and issues) that can be sorted, grouped, customized, saved, and shared. Notable vistas are Support > Inbox and Tickets, Build > Issues and Now, Next, Later, and Product > Parts. Depending on the type of object there are different options for querying, sorting, customizing, and grouping.
Vistas can be grouped by Similarity of the content in addition to other explicit attributes like Owner and Stage.
When you make a change to the default view of a vista, a Save as button appears in the upper-right corner. You can give the list a name, which causes it to show up in the My list section at the bottom of the left-side nav bar. Everyone in the dev org has read permission, so you can share the vista URL if you only want to bring it to their attention. If you want to grant someone else write permission, select the item from My list and click the Share button in the upper-right corner.
Note: Only a certain number of work items can be grouped by similarity. If the Similarity option is not shown in the Group menu, filter the list further.
Duplication avoidance
In traditional systems of record, duplicate work is rampant, and maintenance of the backlog can be an entire job itself. Huge engineering backlogs can have detrimental effects on developers' morale and work velocity.
DevRev helps you avoid duplication during the work creation process. As you're creating a new work item, the Similar Work modal appears and presents potential duplicates. You can also use this modal to link the work you're creating to other work items if appropriate.
Attachments
Files can be attached to conversations, tickets, and issues. The maximum file size is 20 MB.
Unsupported file types
.7z .ade .adp .apk .appx .appxbundle .aspx .bat .cab .cmd .com .cpl .dll .dmg .exe .gz .hta .ins .ipa .iso .isp .jar .js .jse .jsp .lib .lnk .mde .msc .msi .msix .msixbundle .msp .mst .nsh .pif .ps1 .scr .sct .shb .sys .tar .vb .vbe .vbs .vxd .wsc .wsf .wsh octet-stream