Building a queue in Salesforce: Best practices
Please see Building a queue: Best practices for general tips about designing a good queue process.
This page provides tips, suggestions, and best practices for those teams that specifically want to use Salesforce as their queue.
Why Salesforce?
Salesforce is a convenient place to manage your queue for a few reasons.
- 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.
- 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:
| Field | Type | Options | Who edits? | Notes |
|---|---|---|---|---|
| Account | Picklist (search) | All accounts | Requesters | Ideally, this would be prepopulated in the Intake Form when requesters create a Customer Trust Case where this context is implied. |
| Opportunity | Picklist (search) | All opportunities related to selected Account | Requesters | Ideally, this would be prepopulated in the Intake Form when requesters create a Customer Trust Case where this context is implied. |
| Product Name | Pick Multiple | All the products that you offer | Requesters | So that your requesters can indicate which product(s) are in scope of the request |
| Request Type | Pick One | Questionnaire, One-off question, Document Request | Requesters | Populate with whatever services within Customer Trust you want to use the Queue for |
| Subject | Free Text | Requesters | ||
| Description | Free Text | Requesters | ||
| Status | Pick One | Untriaged, Ready to be picked, Awaiting input, Working, Closed | Customer Trust team (and Sue) | New requests should go into the "Untriaged" status by default. |
| Assignee | User field | Customer Trust team (and Sue) | So that a member of your team can indicate that they are taking the case. | |
| Conveyor Questionnaire Link | URL | Customer Trust team (and Sue) | This will contain the link to the questionnaire in Conveyor. | |
| Internal Notes | Free Text | Customer Trust team (and Sue) | For Customer Trust team notes that may arise when handling the case. |
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.
| Field | Type | Options | Who edits? | Notes |
|---|---|---|---|---|
| Effort | Pick One | Small, Medium, Large, Extra Large | Customer Trust team (and Sue) | A "SWAG" estimate of how much time it takes to complete a request. |
| Case Closed Reason | Pick One | Completed Request, Cancelled Request, | Customer Trust team (and Sue) | Provides more granularity about why the case was closed. |
Updated 20 days ago