Work is defined as anything that requires some activity to be performed by a human or machine; it must have an owner and will require some level of effort.
Connect front-office and back-office work with DevRev to collapse silos, avoid work duplication, preserve context, and more.
These are the default work types available in DevRev.
|Conversation||A conversational work item that may be escalated to a ticket|
|Ticket||A work item created by the customer or consumer|
|Issues||A work item createdby the builder or maintainer|
|Task||A work item typically used to break down larger work|
Conversations → Ticket → Issue → Task#
Conversations 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 front office support, sales, and customer success staff. (you can learn more about the PLuG here)
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.
Later on, a software engineer may decide to work on this ticket by creating an Issue and breaking that issue into smaller pieces with Tasks.
The important thing to note in this flow is the preservation of context. Between every integration hop and side-conversation, important details that help define the ‘why’ behind work is lost. In this case, the customer conversation and ticket are linked together and that context defines the problem and requirements for anyone that works on this issue.
Ticket vs. Issue#
The distinction between Tickets and Issues in DevRev is especially important and bears repeating. A ticket comes from the front office, is usually associated with a part of the product, and can come from both internal and external users. On the other hand, an issue 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 an end user into issues as they see fit, and delegate the work to other team members if necessary. Both tickets and issues are always associated to Rev Parts, which you can learn more about here
Here's a quick way to determine whether you should be creating an issue or ticket.
Deflection and deduplication#
DevRev proactively gets ahead of duplicate work during the work creation process using work deflection. As you're creating a new work item, the "Similar Work" modal will appear and present potential duplicates. You can also use this modal to link the work you're creating to other work, if appropriate.
In traditional systems of record, duplicate work is rampant, and maintenance of the backlog can be an entire job in and of itself. Huge engineering backlogs can have detrimental effects on developers, morale, velocity, etc. One way DevRev gets ahead of that is with work deflection.
Query across objects in DevRev using tags. From DevOrg settings, users can view the collection of all existing tags, their descriptions, and create or make edits from there. Tags enable "Folksonomy" (in contrast to taxonomy), which is typically done by individuals for their personal use to add attributes to data. Tags have low cardinality with sparse mappings, leaving most objects untagged (null value or "N/A"). Fields, on the other hand, should be well-defined for all objects—well-defined objects do not have a lot of nulls.
Associate GitHub events with Work#
Instead of manually updating issues, save time by assocating GitHub events with work. You can view all GitHub commits, branches, and pull requests in the work's "Events" tab and automatically update work status. You can read more about GitHub integration here