A service desk promises to resolve an incident within four working hours. The ticket arrives late on a Friday. Can the IT service management platform calculate the right deadline, account for a pause, and explain the result afterward?
That is a useful question for organizations considering IFS assyst. IFS describes self-service, knowledge sharing, request tracking, and workflow automation among its capabilities. A demonstration built around a real service commitment can show how the proposed configuration would work for your team.
Start With a Shared Service Scenario
Choose a representative incident with a response target and a separate resolution target. Define the support hours, the events that start and stop each clock, and any permitted pauses. Give every vendor the same rules before the demonstration.
For an organization assessing Assyst, Matrix 42 ITSM is another platform option to test against those rules. Compare the results alongside each product’s documentation, including the effort required to configure them.
Take a hypothetical ticket logged on Friday at 4:00 p.m. The desk operates from 9:00 a.m. to 5:00 p.m., Monday through Friday, and no holiday affects the period. Its resolution target is four business hours, starting when the ticket arrives.
One hour passes on Friday. The remaining three run from 9:00 a.m. to noon on Monday, making noon the expected deadline. Have each vendor configure the scenario and show the deadline on the ticket.
Test the Rules Behind the Deadline
A service-level agreement can contain several targets, each tied to a different event. A response target might end when an agent contacts the user, while a resolution target might end when service is restored and the ticket is marked resolved. Agree on those definitions before judging the calculation.
The demonstration should also show how the platform selects a target. Does it use the affected service, priority, location, or a combination? If an agent changes the priority after logging the ticket, what happens to the deadline?
Support calendars deserve particular attention across European operations. Teams may use different public holidays, local working hours, and time zones for different services. Have the vendor show how an administrator sets those calendars and assigns a ticket to the right one.
Keep track of the setup needed to reproduce the demonstration, including any extra configuration, integration, or licensing. A feature shown in a demo is only useful for comparison when buyers understand what the proposed package includes.
Pause the Clock and Trigger an Alert
Add an exception to the Friday ticket. Suppose the agreed rules allow the resolution clock to pause while the team waits for information from the requester. If it pauses on Monday from 10:00 a.m. to 11:00 a.m., the expected deadline moves from noon to 1:00 p.m.
Check who can apply the pause, how the reason is recorded, and how the clock resumes. Then try a status change that should leave the clock running. A pause rule that is too broad can improve a report without reflecting the service users received.
The same ticket can test escalation. Can the platform notify the appropriate team before the deadline? How is the warning threshold configured, and what happens if ownership changes? Look for the notification and its recipient, rather than relying on a settings screen.
Check the Evidence Behind the Report
Once the ticket is resolved, inspect its timestamps, pause history, target, and final result. A manager should be able to see why it met or missed the commitment without reconstructing the sequence from memory.
Then move from the ticket to a report. Can the team filter results by service, priority, or support group? Can it examine the tickets behind a summary figure, including those that were paused or reassigned?
IFS’s assyst 26R1 release overview describes reporting visualizations and filters. Buyers should see how their own service-level definitions appear in the proposed configuration and reports.
Check Deployment and Ongoing Ownership
The service-level test is only part of the decision. Confirm which deployment model is available for the proposed purchase, where production data and backups will be stored, and where support personnel may access them. Document those arrangements in the contract: a European hosting location alone does not answer every data-handling question.
Establish who will maintain the rules after launch. A routine change, such as adding a local holiday or revising a target, is worth demonstrating too. Find out whether an internal administrator can make it or whether outside assistance is needed.
Record what each platform demonstrated, what required additional configuration, and what remains unanswered. The resulting evidence gives the selection team a basis for choosing software that fits the services it must deliver.