QA Request Ticketing System

BACKGROUND

As part of our ongoing commitment to enhancing research capabilities and optimizing processes, we are excited to announce the launch of our Wayfair B2B and B2C insight communities. These branded research panels, comprised of our valued customers and suppliers, represent a dynamic platform for gathering insights directly from key stakeholders.

In line with this initiative, we are dedicated to empowering our direct stakeholders—UX researchers, product designers, and product managers—with the autonomy to independently initiate and conduct research within these communities. By reducing the need for end-to-end support from Research Ops, we aim to foster a culture of agility and ownership in our research endeavors.

To uphold the quality and integrity of research projects conducted within these communities, we have introduced a Quality Assurance (QA) request form. This form serves as a tool for relevant stakeholders to request quality checks on their studies before they go live, ensuring that each project meets our high standards for excellence and accuracy.

PROBLEM TO SOLVE

How can we support our direct stakeholders in QA-ing their research activities before launching on insight communities at a reasonable timeframe?

IDENTIFY USER JOURNEY & TOUCHPOINT

To understand how our stakeholders currently reach out to Research Ops for support, I mapped out all the flows on a MIRO board to identify where all current user touchpoints are.

After mapping out the user journey, I can see that our stakeholders reach out to us mainly in three avenues:

General Consultation (Office Hours)
Research Project Support
Communities of Practices (COP) / Strategic Initiatives

By assessing the past submitted request data, in addition to our team's general Slack channel, I noticed that Research Project Support and General Consultation are the two main avenues where we received formal QA requests for research activities.

DESIGN & SOLUTIONS

I reported the findings to my immediate team and proposed a solution to build an embedded request system on the existing Research Calendar on Airtable, where all current and planned research activities are housed. The main advantages of creating this system on the research calendar are:

Users are already familiar with using the research calendar
Able to set up automated notifications to notify requesters of the status of their request
Easy to track the number of requests received

Above is an overview of the QA request ticketing system on Airtable. Once a research activity is added to the research calendar, the specific activity name and the requester’s name will auto-populate under the QA Ticket tab, where users can request a QA for their study if they need it.

There are two QA options for the users to choose from depending on their need:

Need QA on Document

This option is for any feedback on research brief (i.e. screener, survey questionnaires, etc.)

Ready for QA on Alida (insight community software)

This option is to QA acitivities that have already programmed on the platform before launching

For the users, they are required to provide information on:

Areas need QA
Users provide a brief description of what and which areas they need help.

Link to Documents
Users provide a link to documents and/or activities test link.

Need QA from Research Ops
Users select which types of QA they need from the Research Ops team. This column is where the automation trigger is, meaning Research Ops will receive a notification once users select either of the QA options.

For Research Ops, once we receive a QA request, we will fill in:

Ticket Assignee
The member of Research Ops who picks up the QA ticket.

QA Status
Status of the QA

QA Feedback
Any feedback or suggestions we provide to users to program their activity on the tool platform or make changes before launching

FLOW OF THE QA REQUEST

I set up automated notifications on Airtable (task management software) throughout the request system to keep both users informed the status of their request and Research Ops informed when a ticket is submitted.

RESULTS

After the 3 months we implemented this QA request system, we noticed that:

Reduced chances of QA tickets getting lost in the process.
Reduced the rates of QA ticket’s resolve time to 3 days on average.
Users are satisfied with the communications that keep them informed about their request and able to plan their project timeline accordingly.

Back to Home Page

Page updated

Google Sites

Report abuse