A help desk software trial should spend most of its time on one question: does the SLA clock count time the way your service level agreement says it should? Features lists, screenshots and demo queues all look fine. The clock is where tools quietly differ, and it decides whether the numbers you report to your customers are true.
I covered what a help desk is and what it does in an earlier post on the basics. This one is about the buying decision, and the test that is worth more than any checklist: ten tickets, written in advance, pushed through the trial the way your real customers would push them.
Why test the SLA clock before anything else?
Because every other feature is visible and this one isn’t. You can see in thirty seconds whether a tool turns an email into a ticket. You can’t see whether it counts a Friday 4:30 pm ticket correctly until the following Monday, when somebody asks why the report shows a breach.
Take a 4-hour response target on a desk open 9:00 to 17:00, Monday to Friday. A ticket arrives Friday at 4:30 pm. Counted properly in business hours, it has 30 minutes left on Friday and 3.5 hours on Monday, so it’s due Monday at 12:30 pm. Counted on a 24-hour wall clock, it’s due Friday at 8:30 pm and shows as breached while nobody is at work. Do that across a week and the problem is bigger than one ticket: a desk open 40 hours has 128 of its 168 weekly hours outside the calendar, or 76%, and a wall clock runs through all of them.
Demos hide this. In the vendor demos I’ve sat through, the SLA badge is always green, because the demo tickets are made to be. Your trial tickets have to be made to fail.
What does a good help desk software trial test?
Write the ten tickets before you open the trial account, so the vendor’s setup help can’t shape the test. Each one targets a single behaviour:
- A ticket raised at 4:30 pm on a Friday, to check the business-hours calendar.
- A ticket raised on a public holiday you’ve loaded into the calendar.
- A ticket set to “waiting on customer” for two days, to check the pause.
- The same ticket after the customer replies, to check the clock resumes where it stopped.
- A ticket reassigned between two groups, to check the clock doesn’t restart.
- A ticket reclassified from low to high priority, to check the new target applies from the moment of the change and the time already used is kept. How the tool decides priority is only as good as your ticket categories, so load yours first.
- A ticket with two different customers’ targets, if your contracts have tiers like the ones in my tiered SLA matrix.
- A ticket that is about to breach, to check who is warned, how and how early.
- A ticket that does breach, to check where it appears and who it escalates to.
- A closed ticket you reopen, to check whether the original clock or a new one applies.
Score each one pass or fail. A tool that fails two or more is a tool whose reports you’ll be explaining for years.
How do you check the tool’s numbers by hand?
Build a small workbook before the trial starts. One sheet, named Trial, with a heading in row 1 and one ticket per row, so the ten tickets sit in rows 2 to 11. Column A holds the ticket name. Column B holds the date and time it was opened. Column C holds the hours the clock should be paused. Column D holds the target in hours. Column E is the due time you worked out yourself, on paper, from the calendar and the rules in the agreement. Column F is the due time the tool reports. Column G is the verdict.
Column G is the only formula, and it is short: =IF(ABS(E2-F2)*1440<=1,”Pass”,”Fail”). Read it from the inside out. E2 minus F2 is the gap between your due time and the tool’s, and Excel stores times as fractions of a day, so the gap is a fraction too. ABS strips the sign, so early and late count the same. Multiplying by 1,440, the number of minutes in a day (24 hours x 60 minutes), turns the gap into minutes. The IF then says Pass when the gap is one minute or less, and Fail when it isn’t. Copy it down rows 2 to 11.
Row 2 is the Friday ticket. B2 is Friday 16:30, D2 is 4, and C2 is 0 because nothing pauses it. Your E2 is Monday 12:30, from the arithmetic earlier: 30 minutes left on Friday, 3.5 hours on Monday, 9:00 plus 3.5 hours. If the tool reports Friday 20:30 in F2, the gap is 64 hours, which is 3,840 minutes, so G2 says Fail. A single cell at the bottom, =COUNTIF(G2:G11,”Pass”), counts the passes in that column. Eight passes out of ten is 80%, and the two fails are the two conversations you take to the vendor.
Have a second person work out column E without seeing the tool’s answers. If you both land on the same due time and the tool doesn’t, the tool is wrong. If you land on different ones, the agreement is ambiguous, and that is worth knowing before a customer finds it for you.
How should the pause rules work?
This is the test most buyers skip, and it’s the one customers notice. If you wait on the customer for information, the clock should stop. If it doesn’t, your team gets blamed for a delay that was the customer’s.
A worked example, with figures I computed for an 8-hour resolution target on the same 9 to 5 calendar. A ticket opens Tuesday at 10:00. Your team works it for 5 hours and by Tuesday 15:00 asks the customer a question. The customer answers Thursday at 11:00. With no pause, the target falls due Wednesday at 10:00, so the ticket breaches while you are waiting. With a correct pause, the 3 remaining hours resume Thursday at 11:00 and the target falls due Thursday at 14:00. The same ticket is a breach in one tool and a success in another.
Pause behaviour differs between products, and the documentation is the quickest way to find out how a given tool recalculates the due time. One vendor’s help pages show that placing a ticket on hold freezes the timers and then recalculates the due time from the time spent on hold and the business-hours settings. Read the equivalent page for every tool on your shortlist before you start, then check the trial matches what it says.
Does installed or hosted change the trial?
It changes the setup, not the test. An installed product runs on your own server, so your trial includes the server, the database and whoever has to patch them. A hosted product is usually ready in an afternoon, but your ticket data lives with the vendor, so ask about exports and what you can take with you if you leave. Whichever you pick, run the same ten tickets. A clock that fails on a hosted trial account will fail in production too.
Test the reporting at the same time. Pull a report of the ten tickets and compare every response and resolution time with your own arithmetic from a spreadsheet. If you can’t reproduce the tool’s numbers by hand, you can’t defend them to a customer who disputes a credit, and internal and external targets only work if both sides can trust the measurement.
What do you do with the result?
Put the scores in a simple table: ten rows, one column per tool, pass or fail. Add one column for what the tool needed to pass, because a pass that depends on a custom script or a paid add-on is a cost you should price now. Then bring the table to the vendor and ask for each failure to be fixed or explained in writing before you sign. ITIL, the service management framework published through Axelos, treats the agreed target and the measurement of it as one job, and that is the right way to read the table: a target you can’t measure is a wish.
One last test is cheap and often decisive. Ask the vendor to reproduce your Friday 4:30 ticket live, on your calendar, on a call. A tool that does it in two minutes has probably been built by people who run desks. A tool that needs a week to look into it will need a week every time you need it.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
