Faldgruber når du skal udviklet et bookingsystem i WordPress

Automatisering af arbejdsopgaver i virksomheder er blevet det nye sort på direktionsgangene. Fordelene og mulighederne er mange.

Det kunne fx være automatisering af manuelle reservationer, som et bookingsystem til reservationer af mødelokaler, festlokaler eller hotelværelser vil kunne klare. Ligeledes er booking af rådgivning af medarbejdere i en virksomhed blevet enormt populært, som det fx kan ses hos HUSET Middelfart, hvor man kan booke rådgivning til ens nye badeværelse.

3 fordele ved at automatisere en arbejdsgang til et bookingsystem

Først og fremmest sikrer du en ensartethed af alle reservationer. Du sikrer, at du får alle informationer krydset af, og at kunden ikke glemmer at nævne relevant information, eller at kontorassistenten/kundeservicemedarbejderen ikke glemmer at notere noget.

En anden klar fordel er, at kontorassistenten nu får endnu mere tid til andre relevante opgaver, som sikrer bedre brug af medarbejderens ressourcer. Sidst men vigtigst er, at du giver kunden en bedre købsoplevelse ved, at de selv kan styre processen og tilgå bookingsystemet på et tidspunkt, som passer dem – selv uden for kundeservice åbningstid.

Hvad er faldgruberne?

Selvom der er mange fordele, så er der mange faldgrupper, som programmerings bureauet Morning Train har oplevet i arbejdet med at lave bookingsystemer for deres kunder.

Her følger konkret 5 anbefalinger, som vil spare dig mange timer ved udvikling af dit næste bookingsystem.

• Involver alle beslutningstagere/interessenter (uanset om det er internt i din virksomhed eller for en kunde) og lav en konkret forventningsafstemning af det ønskede bookingflow
  1. I hvilken rækkefølge skal bookingflowet køre?
  2. Hvad giver mening for slutbrugeren? Hvis det er en lokalebooking, er det så vigtigst at finde et bestemt lokale eller et bestemt tidspunkt først? Tænk logikken grundigt igennem
• Få defineret alle interaktioner med bookingflowet fra start
  1. Skal det være muligt at redigere en booking, eller skal den slettes og laves på ny?
  2. Skal en booking accepteres af en admin med højere rettigheder, eller kan kunden få en bookingbekræftelse med det samme?
  3. Skal der tilkobles en betalingsløsning, eller er der blot tale om en reservation?
• Overvej om alle ønskede funktioner er relevant fra start, eller om målsætningen fra start skal være en light 1.0 version af kernefunktioner
  1. Det kan have væsentlig betydning for budgettet, hvor mange funktionaliteter og hvor kompleks, at logikken skal være. Hvis du er usikker på effekten af et bookingsystem ved oprettelse af et bookingsystem, så kan det oftest anbefales at starte ud med en light version 1.0. Det er dog vigtigt, at du i strukturen har taget højde for at kunne tilkoble fremtidige nye funktionaliteter ind uden at skulle starte fra start.
• Baseret på forventningsafstemningen af flowet og ønskede interaktioner skal du have kortlagt en konkret skriftlig kravspecifikation som ramme

1. Især hvis du udvikler på vegne af en kunde, så skal du have nedskrevet en komplet kravspecifikation for både dig og din kundes skyld, hvor alle forhold skal være beskrevet eller afgrænset. På den måde sikrer kunden, at han får præcis den ønskede løsning, og du som udvikler sikrer, at du ikke udvikler nogle funktioner forgæves.

• Som udvikler sørg for at have et overblik over strukturen i din kode
  1. En god struktur på din kode baseret på den endelige kravspecifikation er din sikkerhed for som udvikler, at du får taget højde for hele logikken fra start og ikke skal lave ”høker løsninger” til sidst for at få det til at spille.
  2. Husk desuden at lave god dokumentation for dit arbejde, så det både er til at udvide på sigt og vedligeholde.

Hvis du har styr ovenstående 5 punkter, så er du rigtig godt vej til at have den rigtig struktur og forventningsafstemning til at lykkes med dit næste bookingsystem. Happy coding!