Asana is known as project management software. If you were to squint, you might also be able to imagine using it for myriad other use-cases; like ticketing. Companies assessing potential ticketing platforms are vetting for a handful of key features that enable their teams to achieve efficient resolution of customer requests. This is a three-party problem. It includes Agents – the people triaging incoming request, Customers – the people submitting requests, and Admins – the people establishing processes and overseeing the progress of work. This year-long project spanned the gamut of large feature re-designs, to small incremental changes.

Most ticketing processes include an intake form that enables customers to submit help requests. In order to create a truly great intake process, we had to re-think Asana's existing form builder. Before this work, form submissions required manual transposing of submitted information. Now all submissions result in fully connected, data-enriched tasks, enabling Agents to get working straight away.

Once a request is received, Agents mark the request as 'In progress' and begin to triage, conversing with their team, and sending updates to the Customer. Previously in Asana tasks could only be in a state of either 'complete' or 'incomplete' and all conversation was visible to everyone, including the Customer. These two feature changes were critical to getting the Agent workflow right.

A nuanced detail of extending a task's status, was the term Asana used for all inbound work. Tasks. It's small, yet important, because Agents are expecting to work on tickets. We created fully customizable states and enabled Admins to define a custom type as the default for the project. This feature enables Admins to tailor Asana for the workflow of each team, and support a wide variety of use-cases beyond simple completion.

As work progresses, it's critical to the business that Customer requests are resolved in a timely fashion. A service level agreement (SLA) is the mechanism that enables this. SLA is a contract that defines the amount of time Agents have to resolve a ticket. There are two common types: Resolution – the total time it takes to resolve the request, and First Response – the amount of time an Agent has to establish communication with a Customer. The former, Resolution time, is critical to the business and is leveraged in a performance dashboard. The latter, First response, is used by Agents triaging inbound requests. These time values are represented in the UI via timers that begin running when a new ticket is received.

One constraint of this work was to refrain from creating bespoke features that would be unique to ticketing. Instead the objective was to focus on creating features that would be useful across many use-cases. For SLAs this required developing three separate features, that when strung together correctly, resulted in SLA functionality. Those features: a timer, a project schedule – to ensure timers weren't running after hours or over weekends, and a set of rules – called Automations – that associate the timer with various actions.

Enabling users to connect the dots between these features, to create a complete ticketing workflow, was a sizable task. Just getting an SLA right required a fair amount of Asana expertise. In order to lower the bar and enable Admins both new and existing to create these projects, we re-invented Asana created project templates. These templates are complete with Demo experiences and a guided setup. We also created pre-assembled "workflow packages" that enable users to add these features al-a-carte.

We designed the Workflow Library to support discovery and education of Ticketing and its requisite features, but we didn't stop there. The infrastructure and method of bundling together project features, to solve unique use-case problems, set the stage for a completely new direction for Asana. To read more about the Workflow Library, → Continue here.