We krijgen regelmatig de vraag waarom er zoveel velden verplicht zijn in het boekingsformulier, uiteraard willen we hier wel naar gaan kijken, maar we halen graag op wat jullie nu wel en niet zouden willen kunnen instellen in qua formulier.
Ik vind het fijn dat ik zelf kan kiezen wat verplicht wordt en wat niet. Jullie hebben hier al een mooie tab voor “details verplicht”. Op zich zoals het nu werkt, werkt het voor mij prima. Wel mis ik de mogelijkheid van een aantal velden en functionaliteit die wij vervolgens nog via een apart gravity formulier uitvragen…
Geboorte voornamen (Eerste Officiele naam voluit en verdere voorletters. Bij mij bijvoorbeeld Naam is Dirk Verhoeven maar officiele naam voor op mijn officieel post hbo diploma is Henricus J.G. Verhoeven (Eerste officiele naam + verdere voorletters).
Geboorte achternaam. Mensen die getrouwd zijn kunnen de naam van hun partner als achternaam aannemen, op diploma’s wordt echter de officiele geboortenaam vermeld. We kunnen dat tegenwoordig ook geen meisjesnaam meer noemen omdat ook mannen de naam van hun partner aan kunnen nemen.
Dieten; Voor de keuken vragen we op te geven of er speciale dieten zijn. Hier misbruiken we nu het veld personeelsnummer voor, echter vragen we die nog apart uit via een gravity formulier nadat ze zich hebben ingeschreven voor een opleiding via planaday. Zou mooi zijn als dit met alleen de inschrijving planaday kon.
Verder zit er op ons gravity forms formulier nog een webhook trigger om sendinblue (Ons mailing systeem) een contact aan te laten maken. Het zou mooi zijn als we dit ook direct kunnen automatiseren via planaday.
Voor iedere klant die dit gebruikt is de dataset die ze nodig hebben net wat anders. En dat snappen wij. Enkele kun je nu al uit/aan zetten in de Wordpress Plugin zelf.
Maar let op: sommige velden mag je gewoon niet uitzetten omdat de Publieke API deze gewoon nodig hebben bij de boeking en de data die nodig is in Planaday zelf.
Maar goed dat dit gaat komen, want daar kunnen wij wel wat mee. Wellicht moeten we alle velden die er zijn (in de plugin), de wensen etc in Excel zetten en dan kijken wat we wel en niet veilig weg kunnen halen.
Had ik al gezegd dat sommige velden ook afhankelijkheden hebben?
Graag zien wij dat als een cursist zich als particulier aanmeldt ook zijn/haar NAW-gegevens verplicht moet invullen. Dit ivm de later te versturen factuur.
Eigenlijk zou ik het nog een stapje verder willen zien:
verschillende velden zichtbaar maken per sjabloon, binnen PAD zijn momenteel een aantal velden verplicht om een gebruiker in PAD bekend te krijgen, ik meen particulier ja of nee, inloggen ja of nee, naam en email veel meer niet.
Er komt bij ons steeds vaker de vraag of wij een speciale “klanten” pagina kunnen aanmaken waarop wij cursussen aanbieden specifiek voor die klant. Vaak zijn dit incompany trainingen, hierbij is het dus niet nodig dat de cursisten hun naw gegevens aanleveren, alleen hun voorletters, naam en geboortedatum zijn dan nodig.
Dit is nu niet in te regelen middels de plugin, de settings zijn globaal voor ieder cursussjabloon hetzelfde. Misschien is het op te lossen door deze opties in te bouwen in het sjabloon inplaats van dat het in de plugin ingesteld wordt?
Volgende maand ga ik hem verder uitwerken en dan kom ik hier met een voorstel hoe we dit denken te gaan doen. De oplossing zal uiteindelijk moeten werken voor de publiek API (wordpress plugin) en portalen!