Sue, our AI Agent for Customer Trust, is smart enough to work in your existing queue via integrations, without requiring you to change anything about your how you work. You simply tell her your standard operating procedures, and she'll follow your rules just like a new analyst on your team would.

However, some teams that don't have an existing queue, or who want to implement a more formal process for handling requests from customer-facing teams, need guidance about the best practices for implementing such a queue. If that sounds like you, then this page is for you.

This page describes the best practices Conveyor has observed in working with large Customer Trust teams using Salesforce to manage their queue of requests from customer-facing teams.

The basics: What is a queue, and why do you need one?

Many teams start with an informal process for supporting customer requests. At the "most informal" end of the spectrum, customer-facing teams might send a message (Slack, email, etc) to the internal resource responsible for supporting security questionnaires, documentation requests, or one-off security questions. That resource probably keeps a personal to-do list, provides updates when asked, and gets the task done. This approach can work well for very small teams, or teams handling a very small volume of requests.

The problem is: this approach doesn't scale. Before long, that personal to-do list becomes unmanageable, requesters complain about a "black box" and forgotten or lengthy response times, and there are no metrics that can help determine "Is this process working or not?"

If you're handling more than 10 requests per month from customer-facing teams, having a formal process whereby customer-facing teams can submit requests, and those requests can be project-managed to completion, is a good idea. If you're handling more than 100 such requests per month, it's not just a good idea - it's essential.

The basic components of a more formal process are:

1. Intake flow: A simple form or communication channel that customer-facing teams can use to create requests in the queue.
2. Queue: A representation of each request, with metadata to facilitate prioritizing and executing on the requests.
3. Communication channel: Oftentimes, requests in the queue require followup with the requester. It's important to align on clear channels where that communication is expected to occur, with some way of retaining the context of the original request.
4. Standard Operating Procedures (SOPs): Once you've established your process, you'll want to document and share it with customer-facing teams. These SOPs also make for good training material for new hires that you onboard onto your team.

What should we solve for when designing a more formal process?

Principles to keep in mind when setting up a more formal process:

1. Keep it simple for the requesters: Your customer-facing teams likely have other helpdesks that they interact with on a regular basis for support. Creating an idiosyncratic process for Customer Trust can hinder adoption. It's best to keep the process as simple as possible for them, and, if possible, consistent with other helpdesk workflows they may already be using.
2. Design a process that makes it easy to get the task done: Perhaps most importantly, these requests need to get done! As you design your internal process for accepting, making progress on, and wrapping up requests, solve for whatever makes things fast and efficient and avoids requests falling through the cracks.
3. Metadata can create powerful reporting: Some metrics will come out-of-the-box depending on what system you use for tracking requests, such as "time to completion" or "time in status." These metrics can be very helpful for creating reports to monitor the health of this process, or provide visibility to management.

Sometimes, these priorities can conflict. As economists like to say, "There are no solutions, only trade-offs"!

Why Salesforce?

Salesforce is a convenient place to manage your queue for a few reasons.

1. Consistency for requesters: Many customer-facing teams spend their entire day in Salesforce, and are used to requesting help from supporting teams (such as legal, revops, etc.) through Salesforce. Communications can be handled directly in Salesforce so that all information is stored in one system of record.
2. Robust metrics: Salesforce can be used to create very robust reports with data that comes "for free" on most objects, and it can be easy to combine it with other relevant account data that already lives in Salesforce.

The drawbacks of Salesforce are that it can be slow to implement and involve a steeper learning curve for the Customer Trust team members. However, Sue will be the main agent interacting with your queue on your behalf, which mitigates the second drawback.

Salesforce design recommendations

To set up a queue that Sue can interact with, you must use "Cases," a standard object type in Salesforce.

We recommend creating a special type of "Case" (e.g., "Customer Trust Cases") with the following fields:

Your "Customer Trust" case object should also support Chatter, as that will be the primary way to communicate issues or progress updates to Requesters.

Recommendations for advanced reporting

Many teams include additional fields that the Customer Trust team populates when closing the case. These additional fields can for future report-generation. However, asking your team to fill in too many fields when closing a case can interfere with the principle of an easy process.

Luckily, for every request type that Sue handles, she can be the one to fill in these fields for you.