Skip to main content
An evaluation produces a number, but almost nothing in Rulebase acts on the number directly. Routing rules match on Low, Medium, or High; calibration sampling can ask for one band and ignore the rest; charts group results into the same three buckets. Score bands are where you decide what those words mean. The Review card underneath sets how long an agent has to dispute a score before the option disappears. Scoring and Review cards in evaluation settings, showing score bands of 0-50, 51-80, and 81-100, evaluation instructions, and a 14-day contest window

​
Before you start

  • Both cards live under Settings > Evaluations, below Eligibility and Timing in the Configuration part of the settings sidebar.
  • You need an admin role. Without it the fields render but stay disabled.
  • Look at where your scores currently sit before you move a threshold; team and agent scores live under Insights. Otherwise a whole team can end up in one colour.

​
Decide where the bands sit

Rulebase ships with 0-50 Low, 51-80 Medium, 81-100 High. Those defaults treat a score in the fifties as a real problem, which suits teams whose scorecards fail tickets readily. If most of your criteria are pass/fail and a single miss costs 25 points, the same thresholds will file competent work as Medium and your routing will send far more tickets for review than you intended. You set two numbers and Rulebase derives the third.
  1. Under Scoring, click the three coloured badges next to Score bands. The editor expands underneath.
  2. Set the Low maximum. Every score from 0 up to and including this number is Low.
  3. Set the Medium maximum. Medium starts one point above the Low ceiling.
  4. Click outside the field. There is no save button; the change is stored when the field loses focus, and High redraws as everything above your Medium ceiling.
The editor keeps the bands from crossing: the Low ceiling can never reach the Medium ceiling, and the Medium ceiling stops at 99, so a perfect score is always High.
Each evaluation records its band at the moment it is scored. Filters and calibration sampling read that recorded band, so moving a threshold changes which band new evaluations land in without re-filing the ones you already have. Set the bands before you turn on automatic QA, and treat later changes as a before-and-after in your reporting rather than a retroactive correction.

​
Where the bands are used

Routing rules. The QA score and Agent QA score conditions offer exactly Low, Medium, High, and Autozero. A rule that sends low-scoring tickets to a reviewer is really a rule about your Low ceiling, so raising that ceiling quietly widens the rule’s reach. See Create routing rules. Calibration sampling. When you build a calibration you can filter the pool by Agent QA score level, which is how you run a session on the tickets your scorecard was harshest about. Run a calibration covers the rest of that flow. How scores are presented. A ticket’s QA workspace colours its score by band, and dashboard charts that break QA results down into High, Medium, and Low draw their groupings from the same two numbers. A generous Low ceiling makes a lot of competent work look like a problem in every chart you show the team. The colour on a ticket is worked out from your current thresholds, while filters and calibration sampling use the band recorded when the evaluation was scored. Right after you move a threshold, a ticket can look Medium on screen and still answer to a Low filter.

​
Write instructions that apply to every evaluation

The Evaluation instructions row sits under the same Scoring card. It is broader than the per-check instructions on a scorecard: whatever you write here is handed to the AI evaluator on every evaluation it runs, whatever scorecard applies, including the re-scores triggered by criterion feedback. It does not change the scorecard’s structure or points; it changes how the criteria are interpreted.
  1. Next to Evaluation instructions, click Edit.
  2. Write your rules in the editor. Markdown works, and one rule per paragraph is easier to revise later than a single dense block.
  3. Click Save changes.
Edit evaluation instructions dialog with four organization-wide scoring rules about agent knowledge at the time of reply, borderline checks, reply length, and language switching The instructions worth putting here are the judgement calls you would otherwise repeat in every scorecard: how to treat a policy that changed after the ticket closed, whether a short reply can still be complete, what to do when a check could reasonably go either way. Leave anything that belongs to one rubric on that rubric, with Add scorecard additional instructions.
Write these as decisions rather than aspirations. “Award the points and note the reason when a check could go either way” changes scores. “Be fair” does not.

​
Open the contest window

An agent who disagrees with a score can dispute it, and the Contest window decides for how long. The clock starts at the evaluation date, not the ticket’s close date, which matters when your evaluation delay is long or a backlog was scored weeks after the fact.
  1. Under Review, click Add window.
  2. Set the number of days. Anything from 1 to 365 is accepted, and 30 is the starting value.
  3. Click outside the field to save.
To remove the deadline entirely, click the × to the left of the field. That does not block disputes; it means a dispute is accepted no matter how old the evaluation is. Most teams land somewhere between 7 and 30 days. Short windows keep disputes close to the conversation, while a window shorter than your review cadence means agents lose the right to dispute before anyone has discussed their scores with them.

​
What an agent can and cannot contest

The window is one of four gates:
  • An agent can only contest their own evaluation, and only the one currently in effect for that ticket. A superseded evaluation is read-only.
  • The evaluation must have at least one failed check.
  • One open dispute per agent per ticket. The next one waits until the first is resolved.
  • The evaluation must be inside the contest window. Past the deadline, the button stays visible but disabled, and the tooltip names the window length so the agent can see what they missed.
Disputes that land arrive as work for your QA team rather than as a status change on the ticket, and Work contested tickets picks the story up from there.