Clearing readiness
load-test results.
A sample report.
A full extract of the deliverable a UK university would receive at the end of a one-week UCA engagement, completed in the pre-Clearing window ahead of the 2025 cycle. Client identity and call data have been anonymised; structure, methodology and depth of analysis are unchanged.
01Document control & contents
Version control
| Version | Date | Description |
|---|---|---|
| 0.1 | 09 Jul 2025 | First draft circulated |
| 0.9 | 13 Jul 2025 | Client review comments incorporated |
| 1.0 | 14 Jul 2025 | Final — signed off |
Document contributors
| Name | Role |
|---|---|
| UCA Lead Engineer | Test design & execution |
| UCA Solution Architect | Engagement lead & report author |
| Client Telephony Lead | Platform access, sign-off |
Approvals
| Name | Title | Status |
|---|---|---|
| Client Telephony Lead | Head of IT Infrastructure | Approved |
| UCA Engagement Lead | Solution Architect | Approved |
Contents
Disclaimer
This is a sample document. Where real engagements are concerned, this report is confidential. Any unauthorised dissemination or copying of it, and any use or disclosure of any information contained in it, is strictly prohibited. If you have obtained it in error, please inform University Clearing Assurance Ltd as soon as possible.
Although UCA has tried to ensure that the information in this report is accurate, we cannot be held responsible for any reliance that you place on it and we give no warranty in that respect. Nothing shall exclude our liability for any matter that would be illegal for us to exclude.
University Clearing Assurance Ltd · Registered in England & Wales.
02Engagement overview
UCA was engaged to load-test Northbridge University's Clearing contact-centre infrastructure against realistic Clearing-week traffic, ahead of A-level results day on 14 August 2025. The objective: validate end-to-end call capacity from public PSTN through to live Finesse agents, and identify any bottlenecks that would degrade caller experience under peak load.
Scope
Three published Clearing hotlines, each routed through the university's SIP carrier, into the CUBE gateway, then to a Cisco UCCE/CVP IVR estate, and finally to a sample pool of contact-centre agents.
- 3 inbound DDIs, >4000 SIP trunks, round-robin balanced to 12 CUBE gateways
- 3 distinct CVP IVR scripts (course-finder, results-line, callback)
- UCCE (ICM) handles call queuing, routing decisions and agent delivery
- Two sample Finesse agents logged in, set to auto-answer, for end-to-end validation
03Test plan & runbook
Required tests
- Inject 4,000 calls into the IVR platform at a rate of 4 calls per second, with a 25-minute timeout window.
- Test all 3 DDIs; one requires DTMF option selection in IVR before queueing. Calls route to queue; agents log in and set "ready" to test agent delivery.
- Agents are set to auto-answer; manual answer fallback verified.
- UCA disconnects each successful call after 2 minutes; platform timeout terminates any orphans.
- Agents remain on hold until the platform is fully loaded — capacity is measured before drainage begins.
Runbook — 14 July 2025
| ID | Start | End | Duration | Task |
|---|---|---|---|---|
| — | 02:00 | 02:35 | 00:35 | Bridge open · platform check |
| T1 | 02:35 | 03:22 | 00:47 | Run Test 1 — initial baseline |
| T2 | 03:25 | 04:05 | 00:40 | Run Test 2 — post-remediation rerun |
| — | 04:05 | 04:30 | 00:25 | Bridge debrief · close |
Why test in July, not August
Testing in the four weeks before Clearing opens gives the client time to remediate findings and re-test. Testing after Clearing has opened is forensic, not preventative — every issue we find is a candidate failure mode the institution has already lived through publicly.
04Results — Test 1 (initial baseline)
Test 1 was halted before reaching planned capacity. Outbound traffic was reaching only 4 of the 12 CVP servers due to a routing-configuration defect on the client estate, and the IVR script behind DDI ending …5768 was clearing calls prematurely.
By hotline
| Campaign | DDI (anonymised) | Calls | Successful | Failed/Aborted | Success % |
|---|---|---|---|---|---|
| VMs1 | 0800 XXX 5766 | 1,333 | 1,251 | 81 | 94% |
| VMs2 | 0800 XXX 5768 | 1,360 | 688 | 672 | 51% |
| VMs3 | 0800 XXX 5769 | 1,496 | 342 | 1,153 | 23% |
| Total | 4,189 | 2,281 | 1,906 | 54% | |
Success vs failure per hotline
Observations
- VMs1 hotline performed close to expectation — >94% success rate confirms the CUBE-to-CVP path is fundamentally sound when routing is correct.
- VMs2 and VMs3 hotlines failed under load — root cause is routing constrained to 4 of 12 CVP servers, plus a TCL-script disconnect on the …5768 IVR.
- Maximum concurrent calls sustained in test: ~2,240 — well below the 4,000-call target.
Action taken
Test was halted gracefully at 03:22. Client telephony team updated CVP routing configuration in the 3-minute window before Test 2 to distribute calls across all 12 servers. TCL script on DDI …5768 flagged for post-test investigation.
05Results — Test 2 (post-remediation)
Test 2 ran after the client's routing-configuration fix. Overall success rate climbed from 54% to 72%. VMs1 hotline returned a clean 100% pass. Residual issues remain on the …5768 and …5769 IVR scripts — calls reach the CVP voice browser but receive Code 16 (Normal Call Clearing) without ever connecting to an agent, indicating a script-side defect.
By hotline
| Campaign | DDI (anonymised) | Calls | Successful | Failed | Success % |
|---|---|---|---|---|---|
| VMs1 | 0800 XXX 5766 | 728 | 728 | 0 | 100% |
| VMs2 | 0800 XXX 5768 | 1,499 | 1,195 | 304 | 80% |
| VMs3 | 0800 XXX 5769 | 1,246 | 588 | 657 | 47% |
| Total | 3,473 | 2,511 | 961 | 72% | |
Success vs failure per hotline
Observations
- VMs1 returned a clean 100% — confirming the original failure was routing-only, not capacity.
- VMs2 improved from 51% → 80% but still loses 1-in-5 calls in IVR.
- VMs3 stayed below 50%. All failures are Code 16 Normal Call Clearing originating from the CVP voice-browser side — calls are reaching CVP but the IVR is releasing the leg before the caller is queued.
- Maximum concurrent calls sustained: ~1,730. Test was halted gracefully when the IVR-side failure rate stabilised.
Hypothesised root cause
Sample log review on the IVR estate points to two likely defects in the TCL scripts driving DDI …5768 and …5769 — a missing exception handler around the DTMF-input branch, and a stale config reference on the queue-handoff transition. Recommend client telephony team review TCL exception paths and re-validate post-fix.
06Overall summary & recommendations
| Test | Calls made | Successful | Failed | Success % | Verdict |
|---|---|---|---|---|---|
| Test 1 · baseline | 4,189 | 2,281 | 1,906 | 54% | Fail |
| Test 2 · post-remediation | 3,473 | 2,511 | 961 | 72% | Improved · Fail |
Findings
Test 1 had a high abort rate driven by call routing being constrained to only 4 of 12 CVP servers — a configuration defect on the client estate, not a capacity problem. Once the routing was corrected between runs, Test 2 demonstrated a clear improvement (54% → 72% success), and the VMs1 hotline returned a clean 100% pass over 728 calls.
However, IVR-side failures persisted on the …5768 and …5769 hotlines. The voice-browser failed to execute call treatment as expected, and the calls were cleared with SIP Code 16 (Normal Call Clearing) without ever being queued. Sample log inspection points to TCL-script defects — specifically around DTMF exception handling on …5768 and a stale config reference on …5769. These should not be live on results day.
Recommendations
Immediate · before Clearing opens 14 August
- Client telephony team to audit and fix the TCL scripts on DDIs …5768 and …5769. UCA can supply specific log extracts and CVP trace IDs on request.
- Re-test (Test 3) once fixes are in place. UCA's standard engagement includes one retest at no additional cost — recommended in the week commencing 21 July 2025.
- Confirm the post-fix routing configuration is persisted to production (not just runtime).
- Document the agreed peak-load threshold and queue depth before results day.
Sign-off
UCA's recommendation is that the platform is not yet production-ready for Clearing 2025 at the load levels tested. With the routing fix proven and the remaining IVR-script defects addressed, we expect a third test to land >95% across all three hotlines. We have allocated time in the week of 21 July for the retest.
Next step
Book the retest window with your UCA engagement lead — included in your existing engagement, no further commercial discussion needed.
Or, if you'd like to discuss the findings on a 30-minute call before scheduling the retest, we're available same-day in term-time.
Document classification
Confidential — Internal use only.
This sample report is published on universityclearingassurance.com with all identifying client data removed. The full version of any real engagement report is shared only with the named recipients on page 02.