Process best practices
Last updated: September 14, 2026
A Process is two things at once: a signpost Solidroad uses to decide whether it applies to a conversation, and a rubric it grades the rep against. You only ever write two fields, the name and the description, and most matching or scoring problems trace back to one of those two. This article covers how to write both so each job works.
How Solidroad reads a Process
Job | What it decides | What it reads |
|---|---|---|
Matching | Whether this Process applies to the conversation | The name and description, used to generate the matching criteria |
Scoring | How well the rep followed it | The description, read word for word |
Solidroad generates the matching criteria for you from the name and description. Don't hand-edit the generated text directly, edits stick and won't be corrected automatically later. If a Process is matching the wrong conversations, improve the name or description and regenerate instead.
Writing a name and description that match well
Write around what the customer is trying to do, in their own words. "Customers asking for a refund or disputing a charge" works. Internal tool names, macros and queue tags don't.
Add the channel to the name if the Process only applies to one, for example Phone - Cancellation. Leave it out if the Process applies across every channel.
Give every Process a distinct name and description. Near-identical Processes are hard for Solidroad to tell apart.
State the topic in the first line of the description, starting with "This process covers…". It keeps the Process from being matched to conversations it isn't for.
Writing a body that scores fairly
Write the body as the exact checklist you want the rep graded against. Whatever isn't written down isn't scored.
Number the steps, one short, observable action each.
Only include steps a rep can be seen doing in the conversation. A step that only happens in a CRM, or in the rep's head, can't be scored.
Use "If X, then Y" for anything conditional, so a rep isn't marked down for skipping a step that didn't apply.
Say so explicitly if the order matters (for example, "verify identity before discussing the account"). Otherwise Solidroad checks whether each step happened, not the sequence.
Keep each Process to one topic. Split a sprawling document into separate Processes rather than combining them.
Only the human agent's words count. Don't write steps your bot or IVR performs and expect the rep to get credit.
Setting up the scorecard section
Scoring type: Graded for most SOPs, since it gives credit for following most of it. Reserve Pass/fail for compliance-style Processes where any miss should fail the section.
Adherence descriptions: write about degree of adherence, not specific steps, since an auto-detect section can match a different Process each time. For example: Poor - skipped most of the required steps, or followed the wrong process. Average - followed the core of the process but missed one or more steps. Strong - followed all required steps, in order where order matters.
Weight: same as any section, weight process adherence against your soft-skill sections.
You don't need to write exclusion or N/A rules on a Process section. Solidroad handles that automatically when the Process doesn't apply, or when the agent had no realistic chance to follow it.
Reading Process Health
Signal | What it means | The fix |
|---|---|---|
Doesn't reflect real conversations | Matched conversations don't resemble the Process | Rewrite the description in customer language, then regenerate |
Hard to match reliably | Solidroad keeps matching this Process with low confidence | Make the name and description more distinct from similar Processes, then regenerate |
Sections not applicable | The Process is attaching to conversations it doesn't cover | Narrow what the description says it covers, then regenerate |
Agents scoring low | A coaching signal, not an authoring one | Coach the team, or clarify the body if it's ambiguous |
Before you publish
Name states what the Process is for, with a channel word if it's channel-specific
Description opens with "This process covers…", written in customer language
Name and description are distinct from any similar Process
Body is a numbered, observable checklist, one topic per Process
Scorecard section is Graded, unless it's a compliance Process, then Pass/fail
Adherence descriptions describe degree of adherence, not specific steps
Tested against a few real conversations before going live: the right Process matched, and the score would match what you'd have given yourself
Template
Name: Phone - Refund Request
(include the channel if matching should be scoped to it)
Description:
This process covers phone calls where the customer wants a refund or to
dispute a charge.
1. Rep verifies the customer's identity before discussing the order.
2. Rep confirms the specific order or charge in question.
3. Rep states the refund eligibility window (30 days from purchase).
4. If the order is within the window, the rep processes the refund and
states the expected timeline (5–7 business days).
5. If the order is outside the window, the rep explains why and offers
store credit as an alternative.
6. Rep confirms next steps.
Activation criteria: generated for you from the name and description.
Leave it as is.
Related articles
If you have any further questions, contact the Solidroad team via the Help tab in the platform.