ATS-demo voorbereiden met echte use cases

Een ATS-demo bereid je voor door een herkenbare werksituatie te beschrijven, de gewenste uitkomst af te spreken en dezelfde invoer aan iedere leverancier te geven. Laat de handelingen uitvoeren met passende gebruikersrechten. Noteer daarna wat aantoonbaar werkt, wat inrichting vraagt en wat je nog niet hebt gezien.

Zonder die voorbereiding kun je na meerdere presentaties vooral verschillende herinneringen hebben: een mooi dashboard, een snelle zoekactie en een overtuigend verhaal. Je weet nog niet welk systeem de opdracht aankan waar je bureau op vastloopt.

In het kort

• Neem een use case mee die de keuze tussen pakketten echt kan beïnvloeden.
• Gebruik hetzelfde dossier en dezelfde gewenste uitkomst in iedere demo.
• Laat een gewone recruiterrol en een verandering tijdens het proces zien.
• Houd getoonde werking, handmatige oplossing en toekomstbelofte apart.

Welke use cases zijn geschikt voor een demo?

Kies situaties die vaak voorkomen of bij een fout veel extra werk veroorzaken. Beschrijf de taak vanuit de recruiter en de collega die het resultaat nodig heeft. Een use case is concreter dan ‘we willen goede AI’ of ‘het systeem moet gebruiksvriendelijk zijn’: iemand moet er iets mee kunnen uitvoeren.

De Britse overheidsrichtlijn voor technologie-inkoop adviseert onder meer een kleinschalige proef met een moeilijk probleem. Die richtlijn is voor de publieke sector geschreven; hier gebruiken we alleen het praktische idee om software aan een afgebakende taak te toetsen. De overheidsinkoopregels zijn geen voorschrift voor je bureau.

Kies niet uitsluitend een ingewikkelde uitzondering. Je wilt ook zien hoe iemand het dagelijkse werk doet. Een intake verwerken en vervolgens een gewijzigde klantwens vastleggen kan genoeg laten zien om gerichte vervolgvragen te stellen.

Hoe schrijf je één bruikbaar demoscript?

Beschrijf de beginsituatie, de handelingen en het bewijs dat je na afloop wilt zien. Laat de leverancier vooraf weten wat je wilt testen. Zo kan die aangeven welke onderdelen beschikbaar zijn en welke voorbereiding nodig is, zonder dat de afspraak een geheugentest voor de presentator wordt.

Dit is een fictief voorbeeld voor een bureau dat een logistieke teamleider zoekt:

Onderdeel	Instructie voor de demo
Beginsituatie	Er is een klantcontact en een nieuwe vacature met functie-eisen
Eerste handeling	Recruiter legt de intake en de verantwoordelijke vast
Wijziging	De klant verandert de vereiste werktijden na de intake
Overdracht	Een collega opent het dossier en bepaalt welke eis nu geldt
Bewijs	De actuele afspraak is vindbaar en de eerdere afspraak blijft begrijpelijk

Voeg een concreet gegeven toe dat niet zomaar mag verdwijnen, zoals de datum waarop de klant de wijziging doorgaf. Bepaal of dat in een notitie, veld of historieweergave moet terugkomen. De leverancier mag een andere inrichting voorstellen, zolang die tot dezelfde uitkomst leidt.

Hiermee test je geen volledige implementatie. Het script maakt zichtbaar welke vervolgproef nodig is als een antwoord onduidelijk blijft.

Welke gegevens deel je vooraf?

Maak een klein pakket fictieve documenten dat op je echte werk lijkt. Houd namen, contactgegevens en klantinformatie verzonnen. ‘Echte use cases’ betekent dat het proces herkenbaar is, niet dat je persoonsgegevens uit een lopende procedure zonder verdere afspraken moet verspreiden.

Lever ook een blad met verwachte uitkomsten mee. Vermeld welke velden bekend zijn en welke juist leeg moeten blijven. Zet een documentdatum op een oudere intake, zodat een later toegevoegd bericht niet ongemerkt dezelfde actualiteit krijgt.

Geef iedere leverancier dezelfde versie. Als je het script na een eerste demo verbetert, noteer de wijziging en bied de eerdere leverancier een gelijke kans om dat geval te laten zien. Anders vergelijk je verschillende opdrachten terwijl je denkt dezelfde systemen te beoordelen.

Wie moet tijdens de demo meekijken?

Laat iemand deelnemen die de taak dagelijks uitvoert en iemand die verantwoordelijk is voor de inrichting of het besluit. Spreek af wie de vragen stelt en wie de waarnemingen vastlegt. Dat voorkomt dat de notities eindigen als een verzameling indrukken zonder eigenaar.

Vraag om de recruiterrol te gebruiken waar dat past. Een beheerder kan vaak instellingen wijzigen die een recruiter niet hoort te kunnen aanpassen. De route moet ook werken voor de persoon die het dagelijkse werk straks doet.

Laat die collega, indien mogelijk, zelf een handeling uitvoeren. Kijken naar iemand die het systeem kent is anders dan zelf de gewijzigde werktijden terugvinden. Noteer waar uitleg nodig is. Dat kan een trainingsvraag zijn, een onduidelijke inrichting of een ontbrekende mogelijkheid; je hoeft niet meteen een oordeel te forceren.

Hoe leg je bewijs vast zonder schijnprecisie?

Gebruik een beoordelingsblad met korte waarnemingen. Een totaalcijfer met veel decimalen wekt meer zekerheid dan de demo geeft. Eerst moet duidelijk zijn wat er gebeurde en onder welke voorwaarden.

Uitkomst	Wat je vastlegt	Mogelijke vervolgactie
Getoond in de beschikbare omgeving	Handeling, rol en zichtbaar resultaat	Door naar een proef met eigen gebruikers
Kan na inrichting	Welke instelling of begeleiding ontbreekt	Laat inrichting en kosten concretiseren
Alleen handmatige omweg gezien	Extra werk en verantwoordelijke	Bepaal of de omweg aanvaardbaar is
Niet aangetoond	Open vraag of toekomstige functie	Laat het punt open tot er bewijs is

Een uitleg over een toekomstige functie is geen mislukte demo, maar ook geen bewezen antwoord op een eis voor ingebruikname. Houd dat onderscheid vast. Een aantrekkelijke presentatie van andere functies maakt een ontbrekende vereiste niet minder belangrijk.

Bewaar eventuele screenshots of opnamen alleen volgens de afspraken met aanwezigen en met passende gegevens. Een korte schriftelijke bevestiging van de getoonde route kan genoeg zijn.

Wat vraag je na de presentatie nog na?

Stuur de open punten terug als concrete vragen. ‘Kan het systeem historie bijhouden?’ is breed. ‘Kan onze recruiter de oorspronkelijke werktijdeis en de latere klantwijziging terugvinden zonder beheerdersrechten?’ geeft de leverancier iets om te bewijzen.

Vraag ook in welk abonnement de getoonde functies zitten, welke koppelingen nodig zijn en welke inrichting iemand nog moet uitvoeren. Een demo-omgeving kan mogelijkheden bevatten die niet automatisch in jouw gekozen pakket of gebruikersrol beschikbaar zijn.

Plan voor een zwaarwegend open punt een kleine vervolgproef. Leg vast wie die uitvoert en welke uitkomst de vraag beantwoordt. Je hoeft een onbekend punt niet als nul te scoren of alvast als opgelost te behandelen.

Hoe gebruik je dit bij een Simply-demo?

Simply’s ATS en CRM beschrijft een instelbaar gegevensmodel met velden, relaties en rechten. Vertaal dat naar jouw use case: waar legt de recruiter de gewijzigde werktijden vast, en wat ziet de collega daarna? De productomschrijving geeft richting aan de vragen; de demo moet het gedrag in jouw gekozen route laten zien.

Vraag een demo aan en stuur je korte script vóór de afspraak toe. Zet de afspraak niet vol met ieder mogelijk toekomstplan. Zorg dat de belangrijkste onzekerheid aan bod komt en reserveer ruimte voor de uitzondering die je hebt voorbereid.

Loop na afloop met dezelfde collega’s het beoordelingsblad door. Als iedereen kan aanwijzen welke vraag is beantwoord en welke nog openstaat, heeft de demo haar werk gedaan. De koopbeslissing volgt uit die bevindingen samen met de kosten en voorwaarden.