Process Best Practices

Why this guide exists: A Process is two things at once. It's a signpost Solidroad uses to decide "does this apply to this conversation?" and it's a rubric Solidroad grades the rep against. The signpost is generated for you; the rubric is written by you. You only ever write two fields, the name and the description, and almost every "the wrong process matched" or "the process scored unfairly" problem traces back to those two fields. This guide shows you how to write them so both jobs work.

How Solidroad reads a Process

Before writing, it helps to know what happens with your Process behind the scenes.

When a scorecard section is set to Process-linked (auto-detect), Solidroad does two separate things with it:

You only ever write two things: the name and the description. Solidroad generates everything matching needs from them, and reads the description directly for scoring. Get those two fields right, and both jobs follow.

The golden rule: improve the inputs, don't hand-tune the output

Everything in this guide is one idea, said a few different ways:

The matching signal is generated for you. Your job is to give it good raw material, a clear, customer-focused name and description, and to keep the text precise enough to grade against.

Part A — Getting a Process matched to the right conversations

You don't write the matching criteria, Solidroad does. When you create a Process, Solidroad reads your name and description and generates the criteria that actually powers matching. You can edit this generated text, but we recommend you don't, hand-edits tend to reintroduce the kind of language that hurts matching, and won't be corrected automatically later. If matching is wrong, fix the name or description and regenerate, don't hand-tune the generated text.

How matching works, simplified

Solidroad doesn't compare your whole document to the transcript. It looks at what the customer is actually asking for, in their own words, and finds the Process whose generated criteria best matches that. If nothing matches confidently, Solidroad attaches nothing, a wrong match is treated as worse than no match at all.

Rules for writing a name and description that match well

Rule 1 — Write around what the customer is trying to do, in their words.

• 🚫 A description full of internal tool names, macros, and queue tags.

• ✅ "This process covers customers asking for a refund or disputing a charge."

Rule 2 — Put the channel in the name if the Process is channel-specific. Use something like "Email — Cancellation" or "Phone — Cancellation" to scope a Process to one channel. Leave the channel out of the name if it should apply across every channel.

Rule 3 — Give every Process a distinct name and description. If two Processes cover similar ground, make sure their names and descriptions are clearly different from one another. Near-identical inputs make it hard for Solidroad to choose between them.

Rule 4 — State the topic clearly, near the top of the description. Starting with "This process covers…" keeps the Process from being matched to conversations it doesn't actually cover.

If matching is wrong, regenerate — don't hand-edit

Editing the generated matching criteria by hand is possible, but any edit you make sticks permanently and won't be automatically corrected later, so a well-meaning tweak can quietly hurt matching indefinitely. The reliable fix is to improve the name or description and regenerate the criteria.

Part B — Writing a Process that gets scored correctly

How scoring works, simplified

Once a Process is matched, scoring is straightforward: Solidroad sends your entire description, exactly as written, to the AI as the list of requirements, alongside the full transcript. It produces one overall adherence score for the section, backed by quoted evidence. There's no separate step-by-step breakdown, your document is the rubric.

Before scoring, Solidroad checks two things: does this Process actually apply to the topic, and did the agent have a realistic chance to follow it? A voicemail, dropped call, or bot-only interaction is set aside rather than scored 0 unfairly.

Rules for writing a body that scores fairly

Rule 1 — Write the body as the checklist you want graded. Whatever is in the body is exactly what the rep is measured against. If a requirement isn't written down, it isn't scored.

Rule 2 — One observable action per step, and number them. Discrete, numbered steps are easier to check accurately.

Rule 3 — Make every step observable in the conversation. If a step happens in a CRM, or only in the rep's head, and never gets said out loud, it can't be scored. Only write steps a reader could see happen in the transcript.

Rule 4 — Use clear headings and short steps. A dense wall of text scores less reliably than a clean, well-separated, numbered structure.

Rule 5 — Spell out conditional steps as "If X, then Y." This keeps reps from being penalized for skipping a step that didn't apply to that conversation.

Rule 6 — Say what the Process covers, up front. A one-line "This process covers…" reduces the chance a conversation gets wrongly judged off-topic.

Rule 7 — If order matters, say so explicitly (e.g. "verify identity before discussing the account"). Otherwise, Solidroad checks whether each step happened, not the sequence.

Rule 8 — Keep each Process focused on one topic. A long, sprawling document dilutes a single overall score — split genuinely separate procedures into separate Processes.

Rule 9 — Only the human agent's words count. Don't write steps that your bot or IVR performs and expect the rep to get credit for them.

Setting up the scorecard section for process adherence

A Process-linked section works differently from a normal scorecard section — the Process document itself is the criteria, so you don't need to re-type the SOP's steps into the section.

What you actually set on the section:

1. Scoring type — prefer Graded for multi-step SOPs. A Process is scored holistically, with no partial credit by default, so Pass/Fail on a six-step SOP is unforgiving — miss one step and it's a 0. Use Graded (e.g. 0–5) when you want credit for "followed most of it," which is usually what you want for a procedure. Reserve Pass/Fail for compliance-style SOPs where any miss should fail the section.

2. Adherence-level descriptions — about degree of adherence, not specific steps. Because an auto-detect section can match a different Process each time, its Poor/Average/Strong descriptions need to work for any Process that might match — they can't name any one Process's specific steps:

• 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.

3. Weight. Same as any section — give process adherence the weight it deserves next to your soft-skill sections.

You don't need to write exclusion/N/A rules on a process section, Solidroad handles that automatically when the process doesn't apply, or when the agent had no realistic opportunity to follow it.

Quick reference: what goes where

The description does double duty, it's both the scoring rubric and the raw material for matching. One clear, customer-grounded description feeds both jobs.

Common mistakes to avoid

1. A description written in internal language. Tool names, macros, and queue tags don't match what customers actually say. Write in customer terms (Rule A1).

2. Hand-editing the generated matching criteria. Edits stick and aren't auto-corrected. Improve the name/description and regenerate instead.

3. Near-duplicate Processes with similar names and descriptions. Makes it hard for Solidroad to choose the right one (Rule A3).

4. A vague or overly long body. Produces a weaker match and a fuzzier score (Rules B1–B4, B8).

5. Steps the rep can't be seen doing. CRM clicks and internal actions aren't in the transcript (Rule B3).

6. Missing the channel from the name. Makes the Process eligible for every channel, even ones it shouldn't apply to (Rule A2).

7. Re-typing the SOP into the scorecard section, or using Pass/Fail on a long SOP. The Process body is the rubric, keep the steps there, and prefer Graded unless it's compliance.

Reading Process Health

Process Health surfaces signals about how a Process is performing, so you know what to fix:

Calibrate before you rely on it

A new Process should be validated on both jobs, not just one:

1. Check matching first. Run it against real conversations and confirm the right Process attaches to the right conversations, and stays off the ones it shouldn't touch.

2. Then check scoring. On the conversations where it did match, check whether the adherence score and evidence reflect what you'd have scored yourself.

3. Fix the right input. Wrong or missing match → improve the name/description and regenerate the criteria. Unfair score → fix the body.

4. Re-run after every change. Edits don't retroactively change past results, re-run to apply them.

5. Keep watching Process Health once live, it's the ongoing version of this same check.

Quick-start checklist

Before you set a Process live, confirm:

• [ ] Name says what it's for, with a channel word (Email / Chat / Call) if it's channel-specific

• [ ] Description is written around what the customer is trying to do, in their words

• [ ] Description states the topic clearly near the top ("This process covers…")

• [ ] Name and description are distinct from any similar Process

• [ ] You let Solidroad generate the matching criteria, and did not hand-edit it

• [ ] Body contains the real steps — numbered, one action each

• [ ] Every step is observable in a transcript

• [ ] Conditional steps are written as "If X, then Y"

• [ ] One focused topic per Process

• [ ] Scorecard section is Graded (partial credit) unless it's compliance (then Pass/Fail)

• [ ] Section's adherence descriptions are about degree of adherence, not specific steps

Copy-paste Process template

Name: Phone — Refund Request
(include Email / Chat / Call / Phone so matching scopes it to the right channel)

Description / body   ← You write this. It's both the scoring rubric and the
                        raw material Solidroad uses to generate the matching criteria.

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 by Solidroad from the name and
                        description. Leave it alone.

Related Articles

• How to Create and Use a Process in Solidroad

• Process Writing 101 / Cheatsheet

• Scorecard Best Practices

• How to create a scorecard (Quality)

• How to Use Scorecards for Simulations