01
Inloggen met een code
E-mailadres, code, binnen. Geen wachtwoord dat de klant vergeet. Het adres in jullie systeem is de sleutel.
OneDayBuild, het bouwdagmerk van Appfront
Kan klanten zelf hun gegevens laten wijzigen in één dag?
Ja. Een pagina waarop een klant inlogt met zijn e-mailadres en een code, zijn adres, telefoonnummer, rekeningnummer of contactpersoon ziet en wijzigt, en waar die wijziging in jullie systeem landt met een bevestiging. Wat erbuiten valt, is een portaal met alles erin en wijzigingen die een controle vragen, zoals een nieuw rekeningnummer bij een incasso; die gaan door een goedkeuring, en die bouwen we erbij.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Wat er eigenlijk wordt gevraagd
Niet of een formulier te bouwen is, maar welke gegevens een klant zelf mag veranderen, welke een controle vragen en waar de wijziging terechtkomt.
Een verhuizing, een nieuw telefoonnummer, een andere contactpersoon: elke administratie krijgt die wijzigingen per e-mail of telefoon en typt ze over. Bij een deel gaat dat fout, en de klant merkt het als de factuur naar het oude adres gaat. De klant weet zijn nieuwe gegevens het best, en hij zou ze zelf kunnen invoeren als er een plek was.
Die plek is een pagina met twee eisen. De klant moet zijn wie hij zegt: inloggen met een code naar het e-mailadres dat in jullie systeem staat is daar genoeg voor. En niet elk veld is gelijk: een telefoonnummer mag meteen, een rekeningnummer voor een incasso of een tenaamstelling vraagt een controle door een mens of een tweede bevestiging. De pagina kent per veld die regel.
In een dag bouwen we de inlog, de pagina met de gegevens uit jullie systeem, het wijzigen van de vrije velden met een bevestiging, en de gevoelige velden als verzoek dat de administratie goedkeurt. De wijziging landt in het systeem via het koppelvlak, en beide kanten krijgen een bericht. Een portaal met facturen, contracten en meldingen is de stap erna.
02
Vrije velden meteen
Adres, telefoonnummer, contactpersoon, voorkeuren: de klant wijzigt, de pagina bevestigt, het systeem is bijgewerkt.
03
Gevoelige velden met controle
Rekeningnummer, tenaamstelling, e-mailadres zelf: een verzoek dat de administratie goedkeurt, of een tweede bevestiging naar het oude adres.
04
De wijziging landt
In jullie CRM, ERP of ledensysteem, via het koppelvlak. Niet in een mailbox die iemand moet verwerken.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- Een inlog met e-mailadres en eenmalige code, gekoppeld aan de klant in jullie systeem.
- Een pagina met de gegevens die de klant mag zien, en wijzigen voor de velden die u vrijgeeft.
- Gevoelige velden als goedkeuringsverzoek voor de administratie, met een bericht bij akkoord of afwijzing.
- Een logboek van wijzigingen per klant, en de code in je eigen repository.
Buiten scope
- Facturen, contracten, meldingen en de rest van een klantportaal.
- Systemen zonder koppelvlak; de wijziging wordt dan een verzoek in een lijst.
- Identificatie met het landelijke inlogmiddel; e-mail en code is genoeg voor deze gegevens.
- Beheer en de uitbreiding naar meerdere systemen of merken na de dag.
03/06
Hoe de bouwdag verloopt
- Stap 1
Velden indelen
Welke gegevens de klant mag zien, welke hij vrij mag wijzigen en welke een controle vragen. Dat is het gesprek van de ochtend.
- Stap 2
Inlog bouwen
E-mailadres, code, binnen. Met een grens op pogingen en een code die kort geldig is.
- Stap 3
Gegevens tonen en wijzigen
Uit het systeem via het koppelvlak, vrije velden meteen terug, met een bevestiging naar de klant.
- Stap 4
Goedkeuring
Gevoelige velden als verzoek in een lijst voor de administratie, met akkoord of afwijzing en een bericht.
- Stap 5
Testen op rechten
Tien klanten, elk alleen zijn eigen gegevens. Een wijziging die bij een ander landt, is de fout die niet mag.
- Stap 6
Opleveren
Live URL, een link in de factuurmail, code in je eigen repository en een lijst van wat het portaal nog vraagt.
Volgende stap
Typt jullie administratie adreswijzigingen over uit e-mails?
Vertel ons in welk systeem de klantgegevens staan en welke wijzigingen het vaakst binnenkomen. Dan zeggen we of het in één dag werkend te maken is en welke velden een controle houden.
04/06
Eerlijk over wat dit oplevert
- Niet elk veld mag vrij. Een rekeningnummer dat een klant zelf wijzigt, is een fraudekans. Daarom gaan gevoelige velden door een goedkeuring, en dat kost de administratie nog steeds een handeling, maar een kleine.
- Het e-mailadres is de sleutel en het risico. Wie het adres in jullie systeem kan wijzigen, kan inloggen. Het adres zelf wijzigen vraagt daarom een bevestiging naar het oude adres, of een controle.
- Een systeem zonder koppelvlak is een grens. Dan wordt elke wijziging een verzoek dat iemand overtikt: minder fouten, want de klant typte het zelf, maar niet minder werk.
- Klanten wijzigen zelden. De pagina wordt per klant een paar keer per jaar gebruikt. Dat is genoeg, als de link staat waar hij nodig is: in de factuurmail en op de website.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Wijzigingen komen per e-mail en telefoon binnen en worden overgetypt, soms verkeerd.
- Aan het eind van de dag wijzigen klanten hun gegevens zelf, met een controle waar die nodig is.
- Één dag, vaste prijs, code in je eigen repository.
Volledig traject, Appfront
- Het werkt en je wilt facturen, contracten en meldingen erbij in één klantportaal.
- Koppelingen met facturatie en contractbeheer, meldingen en beheer.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Kan een zelfservicepagina waar klanten hun gegevens wijzigen in één dag?
Ja. Een inlog met e-mailadres en code, een pagina met de gegevens uit jullie systeem, wijzigen van de vrije velden met bevestiging, en gevoelige velden als goedkeuringsverzoek. Een volledig klantportaal en systemen zonder koppelvlak vallen erbuiten.
Welke gegevens mag een klant zelf wijzigen?
Dat bepaalt u per veld. Adres, telefoonnummer, contactpersoon en voorkeuren zijn meestal vrij. Rekeningnummer, tenaamstelling en het e-mailadres zelf vragen een controle: een goedkeuring door de administratie of een bevestiging naar het oude adres. De pagina kent per veld die regel.
Hoe weten we dat de klant is wie hij zegt?
Door de code naar het e-mailadres dat in jullie systeem staat. Wie dat adres kan lezen, is de klant, voor gegevens van dit soort. Voor het wijzigen van het e-mailadres zelf gaat een bevestiging naar het oude adres, zodat een gekaapte mailbox niet de sleutel wordt.
Landt de wijziging meteen in ons systeem?
Bij vrije velden ja, via het koppelvlak van uw CRM, ERP of ledensysteem, met een bevestiging aan de klant. Gevoelige velden landen na goedkeuring. Zonder koppelvlak wordt elke wijziging een verzoek in een lijst die de administratie verwerkt.
Kunnen we zien wie wat heeft gewijzigd?
Ja. Elke wijziging staat in een logboek met de klant, het veld, de oude en nieuwe waarde en het tijdstip. Dat is nodig voor een vraag achteraf en het is ook de norm voor persoonsgegevens: de klant heeft recht op inzage in wat er is veranderd.
Is dit hetzelfde als een klantportaal?
Het is het eerste stuk ervan. Een portaal heeft ook facturen, contracten, meldingen en aanvragen. Wie begint met gegevens wijzigen, heeft na de dag de inlog en de koppeling die het portaal ook nodig heeft; de rest komt erbij als blijkt dat klanten de pagina gebruiken.
