Draaiboek en uitvoering Crew en vrijwilligers Materieel en leveranciers

Evenementenplanning software laten maken

De datum ligt vast, alles daaromheen beweegt tot het laatste moment. Een evenement plannen betekent een draaiboek beheren dat elke dag verandert, mensen inroosteren die niet allemaal in dienst zijn, materieel verdelen dat maar op één plek tegelijk kan staan en leveranciers laten aanrijden door één poort. Appfront bouwt maatwerksoftware voor die organisatiekant: van de eerste versie van het draaiboek tot het moment waarop een ploegchef op een veld zonder bereik moet zien wat er zojuist is gewijzigd.

Gratis adviesgesprek Pakket of maatwerk?

Wat evenementenplanning anders maakt

In de meeste planningssoftware is de einddatum de uitkomst van een berekening: er komt werk bij, dus de oplevering schuift op. Bij een evenement werkt het omgekeerd. De datum is verkocht, aangekondigd en vergund, en alles wat niet af komt moet dus kleiner, anders of met meer mensen. Uw planning is geen schatting maar een belofte, en het systeem eromheen moet daarop aansluiten: niet een plan dat mooi oogt in de voorbereiding, maar een plan dat op de dag zelf klopt en dat u nog kunt bijsturen terwijl het loopt.

Daar komt bij dat de uitvoering zich in uren en minuten afspeelt in plaats van in weken. Een truck die een half uur te laat door de poort rijdt, blokkeert de kraan, die de podiumbouw ophoudt, die de soundcheck verschuift. Die ketting is precies wat een spreadsheet niet laat zien: daarin staan tijden naast elkaar, maar niet de afhankelijkheid ertussen. Wie geregeld produceert kent het gevolg, namelijk een producer die de hele opbouw in zijn hoofd meedraagt en de enige is die weet wat een wijziging elders veroorzaakt.

Die logica is niet voorbehouden aan festivals. Een congres met acht parallelsessies, een vakbeurs met standhouders die allemaal op dezelfde ochtend willen opbouwen, een theaterseizoen met wisselende voorstellingen, een sportevenement met vrijwilligers op tientallen posten en een gemeente die een intocht en een braderie in hetzelfde weekend regelt: het patroon is steeds hetzelfde. Er is een vaste datum, een tijdlijn met afhankelijkheden, een gemengde groep mensen die het uitvoert en een verzameling middelen die maar één keer bestaat. Verschilt vooral de schaal en de taal, dan verschilt de software daaronder nauwelijks.

Zit u hier goed? Deze pagina gaat over de organisatiekant: draaiboek, bezetting, materieel en leveranciers. Zoekt u het bredere overzicht van techniek rond evenementen, inclusief de bezoekerskant met ticketing, wristbands, wayfinding en cashless betalen, dan begint u bij evenementen technologie. Gaat het u specifiek om de app voor bezoekers en deelnemers, dan is event app ontwikkeling de betere ingang.

De datum schuift niet mee

Uitloop lost u niet op met tijd, maar met scope, volgorde of extra handen. Uw systeem moet die knoppen tonen.

Alles hangt aan één tijdlijn

Crew, materieel, leveranciers en programma staan niet los van elkaar. Wie er één verzet, verzet de rest mee.

Eenmalig, en dus onvergeeflijk

Een fout in de productie herstelt u de volgende dag. Een fout op de eventdag ziet uw publiek, en die is niet over te doen.

Het draaiboek als levend document

Een draaiboek is geen document maar een tijdlijn. Elke regel beschrijft één handeling met een begintijd, een duur, een verantwoordelijke rol, een plek op het terrein en een verwijzing naar wat er eerst klaar moet zijn. In de praktijk zijn het er meestal drie: het opbouwdraaiboek, dat dagen voor het publiek begint, het showdraaiboek met het programma en de omzettingen ertussen, en het afbouwdraaiboek dat vaak in het holst van de nacht start en waar de meeste ongelukken gebeuren omdat iedereen dan moe is. Ze horen in hetzelfde systeem te staan, want ze delen dezelfde mensen en hetzelfde materieel.

Wat een draaiboek onhandelbaar maakt in een tekstbestand, is dat het per discipline gelezen wordt. De podiumchef wil alleen zijn eigen podium zien, de horecamanager alleen de bevoorrading en de openingstijden, de verkeersregelaar alleen de aanrijroutes en de tijdvakken waarin er bussen komen. Zodra u die uitsneden apart gaat bijhouden, heeft u geen draaiboek meer maar een verzameling documenten die langzaam uit elkaar lopen. De oplossing is één bron met rolgebonden weergaven: dezelfde regels, gefilterd naar wie er kijkt, zodat een verschuiving overal tegelijk zichtbaar wordt.

Even belangrijk is dat regels aan rollen hangen en niet aan namen. Tot vlak voor de opbouw wisselt de bezetting nog, en een draaiboek waarin "Sanne" staat is waardeloos zodra Sanne ziek wordt. Staat er "podiummanager Noord", dan blijft de regel kloppen en weet het systeem meteen wie er op dat moment aan die rol hangt en dus een melding hoort te krijgen. Dat maakt ook de overdracht tussen ploegen mogelijk: de rol loopt door terwijl de persoon naar huis gaat.

Daarnaast moeten afhankelijkheden expliciet zijn. Hekwerk kan pas als de rijplaten liggen, de kraan kan pas als het terrein vrij is, de soundcheck kan pas als de stroom is getest en vrijgegeven. Legt u die volgorde vast, dan kan het systeem rekenen: als de rijplaten twee uur later liggen, welke regels schuiven mee en welke komen in de knel? Zonder die relaties blijft dat rekenwerk in het hoofd van één producer zitten, en dat hoofd staat niet in de cloud. Buffers horen daarbij als eigenschap van de regel, niet als losse marge die iedereen zelf verzint.

Het draaiboek staat bovendien niet los van de afspraken die u met derden heeft gemaakt. Eindtijden, geluidsmomenten, bezoekersaantallen, de bezetting van beveiliging en de plek van de hulpdiensteningang komen ook voor in het veiligheidsplan en in de stukken bij de vergunning. Verschuift u iets in het draaiboek dat daar raakt, dan hoort het systeem dat te herkennen en te markeren, want een programma dat een half uur uitloopt kan een afspraak met de gemeente doorkruisen. Datzelfde geldt voor de omgekeerde richting: een voorwaarde die pas laat wordt aangepast, moet ergens landen waar de mensen die het uitvoeren hem ook zien staan.

Wie werkt er nog met versie 1.4?

Het draaiboek verandert tot op de dag zelf. Dat is geen slordigheid maar de aard van het werk. Het echte risico ontstaat wanneer verschillende mensen op verschillende versies werken zonder dat iemand dat merkt. De ploegchef die donderdag een pdf heeft gedownload, weet zaterdag niet dat de laad- en lostijden zijn verschoven. Daarom hoort versiebeheer geen bijzaak te zijn maar de kern van de functionaliteit: een nummer per vrijgave, een tijdstempel en een auteur per gewijzigde regel, en een overzicht dat per gebruiker toont wat er is veranderd sinds de versie die hij voor het laatst heeft gezien.

Bij wijzigingen die niet gemist mogen worden, is meelezen niet genoeg. Dan wilt u een bevestiging: de podiumchef heeft de nieuwe omzettijd gezien en bevestigd, en wie dat niet heeft gedaan staat op een lijst die de dienstdoende manager kan nabellen. Datzelfde geldt voor vrijgave aan de voorkant. Een draaiboek dat naar leveranciers en naar de gemeente gaat, hoort een status te hebben: concept, vrijgegeven of vervallen. Dat voorkomt dat een leverancier op een conceptversie gaat rijden.

Papier verdwijnt intussen niet, en dat hoeft ook niet. Op een terrein is een geprinte tijdlijn soms sneller dan een telefoon met natte handen. Wat wel moet, is dat elke afdruk een versienummer en een afdruktijd draagt, met een QR-code naar de actuele versie. Zo ziet iedereen in één oogopslag of het papier in zijn hand nog geldig is. Voor organisaties die hetzelfde evenement jaarlijks of op meerdere locaties draaien, komt daar een sjabloonbibliotheek bij: het draaiboek van vorig jaar als startpunt, inclusief de leerpunten die na afloop zijn vastgelegd.

Wat evenementenplanning-software moet kunnen

Deze zes onderdelen hangen samen. Een draaiboek zonder bezetting is een wensenlijst, een bezetting zonder materieel levert mensen op die staan te wachten, en alles bij elkaar is waardeloos als het op het terrein niet werkt. Daaromheen liggen de koppelingen die bepalen of u het geheel ook kunt verantwoorden: verkochte aantallen en tijdsloten uit het ticketsysteem, omdat die de benodigde bezetting bepalen, gewerkte uren naar salarisverwerking en naar de facturen van uw leveranciers, en inkoop en meerwerk naar de administratie. Ontbreken die verbindingen, dan blijft de planning een eiland en gaat de tijd die u wint bij het roosteren weer verloren bij het overtypen.

Draaiboek met versies

Eén tijdlijn met rolgebonden weergaven, een versienummer per vrijgave en per gebruiker zicht op wat er sinds zijn laatste blik is veranderd.

Bezetting op kwalificatie

Diensten die alleen te vullen zijn met mensen die de vereiste papieren hebben, die beschikbaar zijn en die de rusttijd halen.

Middelen met capaciteit één

Verreikers, aggregaten, kleedkamers en zalen als resources die niet dubbel te boeken zijn, inclusief transport en omsteltijd.

Aanlevervensters

Per leverancier een tijdvak voor aanrijden, opbouwen, gereedmelden en retour, met slots op de poort en de losplaats.

Wijzigingen met impactbeeld

Elke wijziging toont wie geraakt wordt, welke diensten schuiven en welke leverancier bericht moet krijgen, voordat u hem doorvoert.

Uitvoering zonder netwerk

Draaiboek, dienst, contacten en checklists lokaal op het toestel, met zichtbare informatieleeftijd en synchronisatie zodra er weer bereik is.

Crew en vrijwilligers met kwalificaties en beschikbaarheid

Bijna geen enkel evenement draait op één soort mensen. Op hetzelfde terrein staan vaste medewerkers, uitzendkrachten, zelfstandigen, vrijwilligers en de eigen ploegen van leveranciers. Ze hebben verschillende afspraken, verschillende registratieverplichtingen en verschillende manieren waarop ze zich aan een dienst binden. Een vrijwilliger die zich afmeldt doet niets verkeerd, een ingehuurde rigger die wegblijft wel. Software die alleen het model van een vast dienstverband kent, dwingt u daarom terug naar de lijstjes ernaast, en juist die lijstjes veroorzaken de dubbele boekingen.

Het eerste dat een planningssysteem hier moet doen, is kwalificaties bewaken op de datum van de dienst en niet op de datum van vandaag. Een BHV-certificaat, een EHBO-diploma, een veiligheidspas, een aanwijzing voor de verreiker of een rijbewijs met de juiste categorie heeft een geldigheidsdatum, en de vraag is niet of iemand het papier ooit had maar of het geldig is op de zaterdag dat hij staat ingeroosterd. Vervalt het ertussenin, dan hoort de dienst nu al te knipperen, met tijd om het op te lossen. Datzelfde geldt voor de minimumbezetting per rol: hoeveel EHBO'ers moeten er per zone staan en klopt dat nog na een verschuiving?

Het tweede is beschikbaarheid in de vorm waarin mensen die echt opgeven. Vrijwilligers denken niet in weken maar in blokken: zaterdagmiddag wel, zondagochtend niet, en het liefst samen met de mensen uit hun eigen groep. Laat u ze zelf intekenen op diensten, dan moet het systeem alleen tonen waarvoor ze in aanmerking komen, anders krijgt u aanmeldingen die u later moet afwijzen. Ruilen onderling is prima, mits het systeem de ruil toetst en niet alleen doorvoert. En overplannen hoort erbij, want een deel meldt zich af of komt niet opdagen; dat is beter op te vangen met een reservelijst en een wachtrij dan met telefoontjes op de ochtend zelf.

Voor betaalde krachten komen daar de grenzen uit de arbeidstijdenwetgeving bij. Voor werknemers van 18 jaar of ouder schrijft de Arbeidstijdenwet ten hoogste 12 uren per dienst en 60 uren per week voor, en gemiddeld 48 uren per week over 16 aaneengesloten weken. De dagelijkse rust bedraagt ten minste 11 uren in elke aaneengesloten periode van 24 uren, die eenmaal per 7 maal 24 uren mag worden ingekort tot ten minste 8 uren als de aard van het werk daarom vraagt. Bij een meerdaagse opbouw met een korte nacht ertussen is dat geen theorie. Bewaak die grenzen op het moment van inplannen, met een waarschuwing in het scherm, niet in een rapport achteraf. Wees daarbij eerlijk over wat uw systeem kan zien: het kent alleen de uren die het zelf heeft gepland, dus wie er in dezelfde week nog elders werkt weet u alleen als diegene het meldt.

Een dienst is bovendien meer dan een tijdvak in een rooster. Er hangt een briefing aan, een plek op de plattegrond, een leidinggevende, soms een instructie die vooraf gelezen moet zijn, en vrijwel altijd een vorm van toegang: een polsbandje, een pas of een zone waar iemand wel of niet mag komen. Komt die toegang uit een ander systeem, dan is de koppeling met het rooster het punt waar het misgaat, want wie zaterdag is ingedeeld maar vrijdag zijn accreditatie kreeg, staat bij de verkeerde poort. Laat de dienst daarom leidend zijn voor wat iemand mag en waar hij naar binnen kan.

Ten slotte moet de bezetting doorlopen tot na afloop. Check-in en check-out op locatie laten zien wie er werkelijk is, gewerkte uren gaan terug naar verloning of naar de facturatie van de leverancier, en dezelfde uren voeden de nacalculatie van het evenement. Rond persoonsgegevens geldt hetzelfde principe als elders: alleen vastleggen wat u nodig heeft, met bewaartermijnen en met rechten per rol, want een ploegchef hoeft geen geboortedatum of medische bijzonderheid te zien om een dienst te kunnen aansturen. Wilt u eerst de bredere roosterkant verkennen, kijk dan bij personeelsplanning software laten maken.

Kwalificaties getoetst op de datum van de dienst, niet op vandaag
Vaste crew, inhuur en vrijwilligers in één rooster met eigen regels
Beschikbaarheid in blokken, met zelf intekenen en getoetst ruilen
Minimumbezetting per rol en per zone bewaakt bij elke verschuiving
Rust- en arbeidstijdgrenzen zichtbaar tijdens het plannen
Reservelijst en wachtrij in plaats van bellen op de ochtend zelf
Check-in op locatie, uren door naar verloning en nacalculatie

Materieel en locaties die er maar één keer zijn

Hier zit het verschil tussen een agenda en een planningssysteem. Een agenda laat overlap gewoon toe: twee afspraken op hetzelfde tijdstip zijn hooguit lelijk. Een verreiker die op twee plekken tegelijk staat ingepland is geen weergavefout maar een productie die stilvalt. Materieel, voertuigen, ruimtes en podia zijn middelen met capaciteit één, en het systeem hoort dat als harde regel te hanteren: bezet is bezet, en wie er toch overheen wil boeken doet dat bewust en met een reden die wordt vastgelegd.

Daarbij is de bezettingsperiode langer dan de gebruiksperiode. Het aggregaat is niet bezet van tien tot vier, maar vanaf het moment dat het op de vrachtwagen gaat tot het terug is in het depot, getankt en gecontroleerd. Dat geldt net zo voor de zaal die na een programmaonderdeel moet worden omgebouwd en voor de kleedkamer die tussen twee artiesten wordt schoongemaakt. Omsteltijd, transporttijd en reinigingstijd horen daarom eigenschappen van het middel te zijn, zodat de planner ze niet elke keer zelf hoeft op te tellen en ze niet vergeet op het moment dat het druk wordt.

Verder loont het onderscheid tussen aantallen en exemplaren. Veertig dranghekken zijn een hoeveelheid: u wilt weten hoeveel er beschikbaar zijn en waar ze staan. Een hoogwerker, een aggregaat of een tribunedeel is een exemplaar met een eigen nummer, een keuringsdatum en een geschiedenis van reparaties. Voor die tweede groep hoort het systeem te weigeren wanneer de keuring afloopt voor de eventdatum, precies zoals het dat bij een verlopen certificaat van een medewerker doet. Na afloop sluit u de cirkel met een retourregistratie: wat is er terug, wat is beschadigd, wat moet eerst naar de werkplaats voordat het weer inplanbaar is.

Wie meerdere producties tegelijk draait, heeft daarnaast een gedeelde pool. Twee evenementen in hetzelfde weekend vechten dan om dezelfde trussen en dezelfde bus. Die schaarste hoort zichtbaar te zijn op poolniveau en niet pas als iemand belt, met per conflict de keuze tussen verschuiven, splitsen of extern bijhuren. Draait uw organisatie zelf ook verhuur van materieel richting derden, dan grenst dit direct aan maatwerk verhuursoftware, waarin dezelfde beschikbaarheidslogica de basis vormt.

Leveranciers en hun aanlevermomenten

Een evenement wordt grotendeels gebouwd door partijen die niet bij u in dienst zijn: podiumbouw, geluid en licht, stroom, hekwerk, sanitair, catering, beveiliging, verkeersregelaars en afvalverwerking. Elk van hen heeft niet één datum maar een reeks momenten: aanrijden, uitladen, opbouwen, gereedmelden, tijdens het evenement bijstaan, afbouwen en retour. Zolang die momenten in mailwisselingen en telefoonnotities zitten, is er niemand die het geheel overziet, en dat merkt u op de eerste opbouwdag bij de poort.

Op de meeste terreinen is de aanrijroute namelijk de echte bottleneck. Er is één ingang, vaak één weg naar het hart van het terrein, en de volgorde bepaalt of het werkt. Wie de trussen aflevert voordat de vloerbescherming ligt, blokkeert de rest van de dag. Tijdvakken per vrachtwagen, gekoppeld aan de losplaats en aan het materieel dat nodig is om te lossen, halen dat uit de improvisatie. Dat werkt pas echt wanneer leveranciers hun eigen gegevens invullen: kentekens, chauffeurs, hoogte en gewicht van de lading, en een aankomsttijd die ze zelf kunnen verzetten binnen de grenzen die u stelt. Die zelfbediening is precies wat een leveranciersportaal op maat doet, alleen dan met een tijdlijn eronder in plaats van een inkoopproces.

Aan het einde van elk leveranciersvenster hoort een gereedmelding: een korte controlelijst met foto en akkoord, ondertekend door iemand van u en iemand van hen. Dat is niet alleen netjes, het is ook het dossier dat u nodig heeft als er later iets misgaat of als een factuur niet klopt. Meerwerk op locatie hoort in datzelfde moment te worden vastgelegd, want een extra toiletunit die op zaterdagochtend mondeling is besteld, is twee weken later niet meer te reconstrueren. En wanneer een leverancier zich meldt met vertraging, hoort dat bericht in het systeem te landen waar het gevolgen heeft, niet in de voicemail van één producer.

De afbouw verdient daarbij evenveel aandacht als de opbouw, en krijgt die zelden. Alles moet in omgekeerde volgorde weg, vaak 's nachts, met mensen die al een lange dag achter de rug hebben en met leveranciers die allemaal als eerste willen laden. Ook hier bepaalt de volgorde of het werkt, en ook hier gaat het mis zonder tijdvakken. Aan het slot staat de oplevering van het terrein of het gebouw aan de eigenaar, met een controlelijst, foto's en een schaderegistratie. Dat is niet alleen een formaliteit: het is het bewijs dat u nodig heeft als er achteraf discussie ontstaat, en het is de invoer voor de volgende editie.

Draaiboek met versiebeheer Rolgebonden weergaven Kwalificatiebewaking Beschikbaarheid en ruilen Resources met capaciteit Omstel- en transporttijd Slotplanning op de poort Leveranciersportaal Gereedmelding met foto Offline-first uitvoering

De wijziging vlak voor aanvang

Vraag een producer naar het spannendste moment en het antwoord gaat zelden over de voorbereiding. Het gaat over de dag zelf: een artiest die vaststaat op de snelweg, een bui die precies over het terrein trekt, een chef die zich ziek meldt terwijl zijn ploeg al onderweg is, een aggregaat dat het begeeft, een straat die door werkzaamheden dicht blijkt. Dan verandert er niet één regel in het draaiboek maar een hele reeks, en verandert die reeks in twintig minuten, terwijl er publiek voor de poort staat.

Daarom is dit geen randgeval maar het scenario waarop uw systeem ontworpen moet zijn. De meeste planningssoftware is gebouwd rond het maken van een plan: velden invullen, opslaan, publiceren. Wat u nodig heeft is software die is gebouwd rond het veranderen van een lopend plan, en dat is een andere architectuur die u aan het begin kiest, niet een knop die u er later bij bouwt.

Dat begint bij wijzigingen als gebeurtenis. Een gewijzigde tijd is geen veld dat wordt overschreven maar een regel in een logboek, met tijdstempel, auteur en reden. Alleen zo kunt u achteraf reconstrueren wat er wanneer is besloten, en dat is precies wat u nodig heeft bij een incidentonderzoek, een klacht of een verzekeringskwestie. Daarnaast hoort het systeem de gevolgen te tonen voordat u bevestigt: welke diensten schuiven mee, welke rol komt onder de minimumbezetting, welk middel is dan dubbel geboekt, welke leverancier moet bericht krijgen. Een wijziging doorvoeren zonder dat beeld is gokken met een zaal vol mensen.

Vervolgens moet de melding gericht zijn. Iedereen alles sturen is hetzelfde als niets sturen, want na de derde algemene push zet de crew de meldingen uit. Wie geraakt wordt, krijgt bericht, in de taal van zijn eigen taak: niet "draaiboek gewijzigd" maar "jouw dienst begint een uur later, meld je bij poort twee". Bij wijzigingen die niet gemist mogen worden hoort een leesbevestiging, met een lijst van wie nog niet heeft gereageerd zodat iemand die kan nabellen.

Twee mechanismen maken het geheel beheersbaar. Het eerste is bevriezen: vanaf een afgesproken moment voor aanvang mag alleen de dienstdoende manager het draaiboek nog wijzigen en dienen anderen voorstellen in. Zo voorkomt u dat drie mensen tegelijk hetzelfde probleem oplossen. Het tweede is scenario's die vooraf klaarstaan. Een weerscenario met een verkort programma, een variant waarin een podium dicht gaat en de bezetting verschuift: die maakt u rustig in de voorbereiding, en op de dag zelf activeert u hem in één handeling. En omdat de storm soms overwaait, moet dat ook terug te draaien zijn.

Als het netwerk op het terrein wegvalt. Op precies het moment dat het spannend wordt, is het mobiele netwerk het minst betrouwbaar. Duizenden bezoekers hangen aan dezelfde mast, een stalen hal of een kelder slikt het signaal, en een weiland had het nooit. Een planningssysteem dat op zulke momenten een laadicoon toont, wordt na één keer niet meer gebruikt. Offline-first betekent dat het draaiboek van vandaag, de eigen dienst, de contactlijst, de checklists en de plattegrond op het toestel staan en dat wijzigingen lokaal worden vastgelegd en later gesynchroniseerd. Belangrijker nog: het scherm toont altijd hoe oud de getoonde informatie is, want iemand die weet dat hij naar een beeld van een half uur geleden kijkt, gaat verifiëren. Iemand die dat niet weet, handelt op verouderde informatie.

Bij synchroniseren komen conflicten voor: twee mensen hebben dezelfde regel aangepast. De simpele oplossing waarbij de laatste schrijver wint, gooit stilletjes werk weg. Beter is samenvoegen op veldniveau met een conflictlijst voor de dienstdoende manager, en een volgorde waarin incidentmeldingen en bezettingswijzigingen voorgaan op rapportage. Houd daarbij rekening met de werkelijkheid van het materiaal: vrijwilligers werken op hun eigen telefoon, de accu is halverwege de dag leeg, handschoenen bedienen geen kleine knoppen en de portofoon blijft gewoon naast de app bestaan. Ontwerp voor die omstandigheden, en houd de papieren afdruk met versiestempel als laatste vangnet.

Pakket of maatwerk? Voor crewplanning, vrijwilligersbeheer en draaiboeken bestaan volwassen pakketten, en voor veel organisatoren is dat de verstandigere route: u koopt onderhoud en doorontwikkeling mee in en uw inspanning verschuift van bouwen naar inrichten. Een overzicht van wat er in Nederland speelt staat bij de beste eventsoftware van Nederland. Maatwerk wordt pas interessant wanneer uw planning over meerdere gelijktijdige producties met een gedeelde pool loopt, wanneer draaiboek, bezetting en inkoop echt in één tijdlijn moeten samenkomen, of wanneer uw vrijwilligersproces zo eigen is dat het niet in een standaardformulier past. Vaak is de tussenweg het beste antwoord: een pakket voor de roosterkant, maatwerk voor de laag die daar bij u overheen ligt. Hoe we die afweging maken leest u bij planning en scheduling software op maat. De keerzijde hoort er ook bij: wat u zelf bouwt, houdt u zelf bij.

Wijziging als gebeurtenis met tijdstempel, auteur en reden
Impact zichtbaar voordat u bevestigt, niet erna
Gerichte melding aan wie geraakt wordt, in taaktaal
Leesbevestiging op wat niet gemist mag worden
Bevriezen vanaf een afgesproken moment voor aanvang
Scenario's die vooraf klaarstaan en terug te draaien zijn
Offline-first met zichtbare leeftijd van de informatie
Conflicten samenvoegen in plaats van overschrijven

Veelgestelde vragen over evenementenplanning-software

Een ticket- of reserveringsplatform regelt de bezoekerskant: verkoop, plaatsen, tijdsloten, betalingen en toegang. Evenementenplanning-software regelt de organisatiekant: het draaiboek, de bezetting van crew en vrijwilligers, materieel, locaties en de aanlevermomenten van leveranciers. De twee raken elkaar op capaciteit, want verkochte aantallen bepalen hoeveel mensen en middelen u nodig heeft. Het blijven verschillende systemen met verschillende gebruikers, en de koppeling ertussen is meestal een doorgifte van aantallen en tijdsloten, geen samensmelting.

Door één bron aan te houden en per rol een eigen weergave te tonen. Techniek, horeca, beveiliging en verkeer zien alleen hun eigen regels, maar die regels komen uit dezelfde tijdlijn, dus een verschuiving landt overal tegelijk. Wat u daarbij nodig heeft is een versienummer per vrijgave, een overzicht van wat er is veranderd sinds de versie die iemand voor het laatst zag, en een leesbevestiging op de wijzigingen die niet gemist mogen worden. Afdrukken mag, mits elke afdruk een versienummer en een tijdstempel draagt.

Alleen als het daarop is gebouwd. Offline-first betekent dat het draaiboek van vandaag, de contactlijst, de eigen dienst en de checklists op het toestel staan en dat wijzigingen lokaal worden vastgelegd en later gesynchroniseerd. Twee dingen zijn daarbij bepalend: het scherm laat altijd zien hoe oud de getoonde informatie is, en het systeem voegt conflicten samen op veldniveau in plaats van de laatste schrijver te laten winnen. Zwaardere onderdelen zoals rapportages en dashboards mogen wachten tot er weer verbinding is.

Door beide groepen in dezelfde planning te zetten, maar elk met hun eigen regelset. Voor werknemers van 18 jaar of ouder schrijft de Arbeidstijdenwet ten hoogste 12 uren per dienst en 60 uren per week voor, met een onafgebroken rusttijd van ten minste 11 uren in elke periode van 24 uren, die eenmaal per 7 maal 24 uren tot ten minste 8 uren mag worden ingekort. Voor vrijwilligers hangt het af van hun status en van wat u zelf heeft afgesproken. Het systeem hoort die grenzen te bewaken op het moment dat u inplant, niet pas in een controle achteraf.

Vaak wel. Er bestaan volwassen pakketten voor crewplanning, vrijwilligersbeheer en draaiboeken, en voor veel organisatoren is dat de verstandigere route. Maatwerk wordt interessant als uw planning over meerdere gelijktijdige producties loopt met een gedeelde materieelpool, als draaiboek, bezetting en inkoop in één tijdlijn moeten samenkomen, of als uw vrijwilligersproces zo eigen is dat het niet in een standaardformulier past. Vaak is de tussenweg het beste antwoord: een pakket voor de roosterkant en maatwerk voor de laag die daar bij u overheen ligt.

De broncode en de documentatie zijn eigendom van de opdrachtgever en staan in een repository waar u zelf toegang toe heeft. Bij oplevering hoort een beschrijving van de architectuur, de datamodellen, de koppelingen en de deployment, zodat een andere partij het kan overnemen zonder eerst te reverse-engineeren. We werken met gangbare technologie, omdat dat bepaalt hoeveel partijen het onderhoud kunnen oppakken.

Gerelateerde diensten

Evenementen technologie

Het bredere overzicht van techniek rond evenementen, inclusief ticketing, wristbands, wayfinding en cashless betalen aan de bezoekerskant: evenementen technologie.

Personeelsplanning software

Roosters, beschikbaarheid, kwalificaties per dienst en koppelingen met HR en salaris, ook buiten de evenementencontext: personeelsplanning software laten maken.

Ticketing en reserveringen

Gaat het juist om verkoop, tijdsloten en reserveringen aan de bezoekerskant, dan sluit een ticketing- en reserveringsplatform daar beter op aan.

Uw draaiboek en uw bezetting onder de loep

Vertel ons hoe uw draaiboek nu wordt gedeeld, hoe u vrijwilligers en betaalde crew naast elkaar inroostert, en wat er gebeurt als een leverancier op de opbouwdag twee uur later aankomt. Uit die drie antwoorden blijkt meestal of een pakket, maatwerk of een combinatie het beste past.

Plan een adviesgesprek info@appfront.nl