Building AI Evaluation Harnesses For UK SME Support Workflows

Tools & Technical Tutorials

7 July 2026 | By Ashley Marshall

Customer support AI should not be approved because the demo sounded helpful. UK SMEs need evaluation harnesses that replay real tickets, score groundedness, tone, escalation and data handling, then show whether the workflow is safe enough to run.

Start With The Support Workflow, Not The Model

The most useful evaluation harness for customer support starts with the workflow, not the model. That sounds obvious, but it is where many SME projects go wrong. A team buys a chatbot, connects Zendesk, Intercom, Freshdesk, HubSpot Service Hub or a shared mailbox, then asks whether the model is good. The better question is narrower: can this system handle our real support work to a defined standard, with the right escalation points and the right evidence when it fails?

GOV.UK's AI Adoption Research gives the business context. Among organisations using or planning to use AI, customer service was already an active or planned area for 46 percent. The same research found that 84 percent of businesses currently using AI reported at least some human input or checking of AI outputs, with 67 percent reporting significant checking. That is the right instinct. Customer support is not a place to treat generative AI as a one-click replacement for operational judgement.

A harness turns that instinct into a routine. For a UK SME, the first step is to map three to five support journeys: password reset, delivery delay, subscription cancellation, billing complaint, product fault, refund request, regulated advice boundary, vulnerable customer mention or data access request. For each journey, record what the AI may do, what it must not do, what evidence it should cite, when it should ask for a human, and what the customer should experience.

What this means in practice: the harness is not a generic benchmark. It is a small copy of your support reality. It should include historic tickets, knowledge base articles, policy pages, CRM context, complaint categories, service-level expectations and examples of awkward customer language. The pass mark should be tied to business outcomes: fewer avoidable escalations, faster first response, fewer wrong refunds, better policy consistency and cleaner handover notes. If the harness cannot describe those outcomes, it is only testing text quality.

Build A Test Set From Real Tickets And Edge Cases

A support evaluation harness needs a test set that reflects both ordinary demand and messy exceptions. Do not build it from invented prompts in a spreadsheet. Start with real tickets, anonymise them, then divide them into scenarios. A good first pack for an SME might contain 120 cases: 50 routine questions, 25 policy or knowledge base checks, 20 complaint or refund cases, 10 vulnerable customer indicators, 10 data protection or account security cases, and 5 adversarial or prompt injection attempts. That is enough to reveal patterns without becoming an enterprise research project.

The test set should preserve the shape of the customer interaction. Keep the original customer message, relevant account facts, available knowledge sources, the expected support action, escalation rule and any prohibited behaviour. For example, a delivery delay case might allow the AI to apologise, explain the carrier status and draft a replacement request, but prohibit invented delivery dates. A billing complaint might require it to cite the refund policy and escalate if the account has already had two manual adjustments. A data access request should be recognised as a rights-related issue, not answered casually from the model's general knowledge.

The ICO's Guidance on AI and data protection is a useful anchor here because it organises AI compliance around UK GDPR principles such as accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights. For customer support, that means your evaluation pack should test more than whether the answer sounds polite. It should test whether personal data is used proportionately, whether the answer is supported by approved sources, whether rights requests and complaints are routed correctly, and whether the system avoids making decisions it has no authority to make.

What this means in practice: create a simple case schema. Use fields such as caseId, scenario, customerMessage, context, allowedSources, expectedAction, mustMention, mustNotMention, escalationRequired, dataRisk, passCriteria and reviewerNotes. Store the cases in JSON, CSV, LangSmith datasets, Promptfoo YAML or a plain repository folder. The format matters less than repeatability. The same cases must be runnable next week, after a prompt change, after a model upgrade and before a supplier renews the connector.

Score The Behaviours That Matter In Support

The quickest way to make an evaluation harness useless is to score it on one vague metric called quality. Customer support needs several smaller scores because different failures matter in different ways. A response can be friendly but wrong. It can be factually correct but breach policy. It can answer the ticket but miss a vulnerable customer signal. It can cite the right article but escalate too late. The harness should break those behaviours apart.

For most SME customer support workflows, use six scoring categories. First, groundedness: does the answer stay within approved knowledge base, policy, CRM and order data? Second, task success: did it take or recommend the correct support action? Third, tone: is it clear, calm, appropriate and on-brand? Fourth, escalation: did it hand off when the case involved complaints, vulnerable customers, payments, legal issues, safety, identity checks or uncertainty? Fifth, data handling: did it avoid exposing unnecessary personal data or requesting information through the wrong channel? Sixth, format: did it produce the structured output your workflow needs, such as summary, draft reply, confidence, source references and next action?

Tooling can stay pragmatic. Promptfoo supports open-source evaluations, assertions, red teaming and CI/CD checks for prompts, models and RAG pipelines. LangSmith evaluation concepts describe datasets, evaluators, experiments, human feedback and offline versus online evaluations. Evidently's LLM evaluation guide explains exact checks, JSON matching, groundedness, relevance, toxicity and LLM-as-judge approaches. An SME does not need every feature. It needs enough structure to stop subjective review becoming a debate after every demo.

A practical scorecard might use hard checks where possible and human or LLM-assisted judgement where needed. Hard checks can verify JSON validity, required fields, forbidden phrases, source citations, escalation flags and whether the reply includes unauthorised refund promises. A reviewer can score tone, helpfulness and policy judgement. An LLM-as-judge can be useful for first-pass review, but it should be calibrated against human decisions and sampled regularly. The counterintuitive rule is simple: automate the boring checks first, then spend human time on the judgement that actually needs a support lead.

Run Regression Tests Before Every Prompt Or Model Change

Evaluation harnesses are most valuable after the first launch. Models change, prompts change, knowledge base articles change, support policies change, and CRM integrations change. A support workflow that passed in March can quietly fail in July because a model handles tool calls differently, a refund policy was rewritten, or a new connector includes fields the assistant should not see. Regression testing is how an SME prevents silent drift.

The DSIT AI Cyber Security Code of Practice says developers and system operators should conduct appropriate testing and evaluation, including testing before deployment, and should document audit trails for the operation and lifecycle management of models, datasets and prompts. The NCSC Guidelines for Secure AI System Development also frame AI security across secure design, development, deployment, operation and maintenance, including logging, monitoring and update management. For support teams, this translates into a simple rule: no production change without replaying representative cases.

What this means in practice: create a release gate. Before changing the system prompt, RAG retrieval settings, model version, helpdesk connector, knowledge base source or escalation logic, run the harness. Compare the new run against the current approved baseline. Track overall pass rate, critical failure count, regression by scenario, average reviewer score, escalation precision, unsupported-answer rate and cases where the output changed materially. If the model improves routine answers but worsens complaint escalation, that is not an automatic upgrade. It is a business decision for the support owner.

The gate can be lightweight. A 20-case smoke test can run on every prompt edit. A 120-case regression pack can run before release. A 300-case extended pack can run before a model migration or major workflow redesign. Use GitHub Actions, GitLab CI, Azure DevOps or a scheduled job if the team has engineering support. If not, run Promptfoo or a simple script manually and store the report in the project folder. The important thing is versioned evidence: prompt version, model version, test set version, result, reviewer and release decision.

Design For Human Review Without Turning It Into Manual Rework

The common misconception is that a proper evaluation harness removes the need for human review. It does not. It makes human review more targeted. Customer support contains judgement, empathy, commercial discretion and risk signals that are difficult to reduce to a pass-fail assertion. The point of AI is not to pretend those signals disappear. The point is to route routine work faster while preserving control over cases that deserve human attention.

The GOV.UK AI adoption research is useful here because it shows that human checking is normal, not a sign of failure. Among businesses currently using AI, 84 percent reported at least some human input or checking of AI outputs and 67 percent reported significant input or checking. For UK SMEs, that should be reassuring. A harness does not have to justify full autonomy on day one. It has to show which parts of the workflow can be trusted, which need review, and which should stay human-only.

Build three review lanes. The green lane is low-risk: password reset instructions, public opening hours, simple order status summaries and draft replies that cite approved sources. These can be sampled after release. The amber lane requires human approval before sending: refunds, complaints, pricing exceptions, account changes, delayed orders, warranty questions and any low-confidence answer. The red lane is immediate handoff: vulnerable customer signals, safety issues, legal threats, payment disputes, identity uncertainty, data protection rights, regulated advice boundaries and prompt injection attempts.

The harness should measure review efficiency as well as answer quality. If the AI creates a draft that takes longer to fix than writing from scratch, the score should reflect that. Add reviewer fields such as usableAsIs, minorEdit, majorEdit, reject, escalationMissed and policyConcern. Over time, this gives the support lead a realistic view of value. A system that produces 70 percent usable drafts and catches red lane cases reliably may be more valuable than one that produces impressive fluent answers but forces staff to inspect every sentence. Review is not a tax on AI adoption. It is where the business decides how much autonomy the evidence has earned.

Turn The Harness Into An Operating Routine

The final step is to make the harness part of operations rather than a one-off project artefact. Many SMEs run a serious test before launch, then lose the discipline once the tool is live. That is risky because support AI sits close to customer trust. It can change the tone of the business, expose weak policies, misread complaints and create evidence that later matters in a dispute. The harness should become the support team's release, monitoring and improvement loop.

Set a cadence. Run a smoke test weekly for active systems. Run a full regression before each prompt, model, connector or policy change. Review live samples monthly. Refresh the test set quarterly with new ticket types, failed cases, policy changes and customer language that the team has seen in the wild. If a serious incident occurs, such as a wrong refund promise, privacy issue, missed vulnerable customer signal or hallucinated policy, add it to the regression pack after remediation. The harness should get harder as the system learns more of the business.

Keep the governance simple but visible. Name a support owner, technical owner and data protection contact. Record which tools are in scope: Zendesk, Intercom, Freshdesk, Salesforce Service Cloud, HubSpot, Microsoft Dynamics, Gorgias, Help Scout, Jira Service Management, Slack, Teams or the shared inbox. Record the model providers and orchestration layer: OpenAI, Anthropic, Google Gemini, Azure AI Foundry, Amazon Bedrock, LangChain, LlamaIndex, Vercel AI SDK, Promptfoo, LangSmith, Arize Phoenix or Evidently. Then record the evidence trail: test set version, run date, pass rate, critical failures, release decision and next review.

A sensible counterargument is that this sounds too technical for a small business support team. The answer is to start smaller. A spreadsheet with 50 anonymised cases, a written scorecard and a monthly review is better than a sophisticated tool nobody maintains. The goal is not to copy enterprise MLOps. It is to create enough repeatability that the business can answer four questions at any time: what did we test, what passed, what failed, and why did we allow this AI workflow to keep running?

Frequently Asked Questions

What is an AI evaluation harness for customer support?

It is a repeatable test system that runs customer support AI against representative tickets, expected outcomes, source material, escalation rules and scorecards. It shows whether the workflow is accurate, grounded, helpful, safe and ready for controlled use.

How many test cases does a UK SME need to start?

A useful first harness can start with 50 to 150 anonymised cases. Cover routine questions, policy lookups, refunds, complaints, account security, data protection requests, vulnerable customer signals and adversarial prompts.

Should the harness use real customer tickets?

Yes, but they should be anonymised or minimised before use. Real tickets preserve the language, ambiguity and edge cases that invented prompts often miss. Keep only the data needed to test the workflow.

Which tools can run AI evaluations?

Promptfoo, LangSmith, Evidently, Arize Phoenix, OpenAI Evals-style scripts, custom Python or JavaScript runners and ordinary CI tools can all help. The best choice depends on whether the team needs simple assertions, human review, RAG evaluation, tracing or release reporting.

What metrics matter most for support AI?

Track groundedness, task success, escalation accuracy, tone, data handling, format validity, reviewer effort and critical failure count. A high average score is not enough if the system misses complaints or invents policy.

How often should support AI be retested?

Run a small smoke test after prompt edits and a fuller regression before model, connector, retrieval, policy or workflow changes. Also refresh the test set quarterly with new cases and any incidents from live use.

Does an evaluation harness remove the need for human review?

No. It helps decide where human review is needed. Low-risk cases may be sampled, medium-risk cases may need approval and high-risk cases should hand off immediately to a trained person.

How does this relate to UK GDPR and ICO guidance?

If support AI processes personal data, the organisation still needs accountability, transparency, accuracy, security, data minimisation and rights handling. The harness provides evidence that those controls have been considered and tested.