Portal bouwen
Opdracht ID: 12422
Budget: € 0 tot € 0
Geplaatst: 19-02-2015
Reacties: 0
Locatie: Leidschendam, België
Laatst gewijzigd: 23-02-2015
Status: Gesloten
Beste Freelancer,
Dit document heeft betrekking op de website van ******NL en is bedoeld als leidraad om een offerte te kunnen maken waarbij een aanneemsom (geen offertes op uurbasis) en een tijdlijn is gespecificeerd..
De situatie m.b.t. de aanvraagprocedure willen we aangepast zien. Ook is onze wens een portal te cre?ren voor onze klanten.
Na eventuele goedkeuring van de offerte is het belangrijk dat, voordat met de uitvoering wordt begonnen, e.e.a. uitvoerig inhoudelijk wordt besproken, zodat er duidelijkheid is naar beide partijen over wat er verwacht wordt en gedaan dient te worden. Dit overleg mag natuurlijk ook plaatsvinden voordat de offerte is opgesteld.
Hoewel we dit document met alle zorgvuldigheid hebben opgesteld, is het niet uit te sluiten dat er kleine wijzigingen, aanvullingen en/of aanpassingen worden verzocht aan de contractant. Voor zover dit de aanvraagprocedure of het portal betreft valt dit binnen de aanneemsom. Indien dit aanvullende functionaliteiten zijn die niet onder de aanvraagprocedure of het portal vallen zal de contractant dit aangeven en hier eerst separaat offreren.
Met betrekking tot de aanvraagprocedure en het portal voor klanten hebben we de volgende wensen.
Aanvraagprocedure
De aanvraagprocedure kost momenteel in de backend te veel tijd en we zijn te afhankelijk van de beschikbaarheid van een medewerker om de aanvraag te verwerken. De handmatige handelingen die geautomatiseerd moeten worden zijn:
1. Het aangevraagde nummer verwijderen uit de lijst zodat deze niet meer beschikbaar is voor bij nieuwe aanvragen
2. De autorisatiecode moet nu handmatig worden toegekend aan het formulier voor de eerste instellingen. Nadat deze is ingesteld moet hij weer handmatig verwijderen uit dit formulier en vervolgens weer toevoegen aan wijzigingsformulier. Met gebruik van een portal kan dit vervallen.
3. Het opmaken van de overeenkomst en deze mailen samen met de algemene voorwaarden en een welkomstbrief met informatie (alle drie in PDF)
Op dit moment maakt ******NL gebruik van twee plugins die betrekking hebben op de aanvraag:
1. Gravity forms
2. Pronamic ideal (zorgt voor de koppeling tussen gravity forms en de betaal API van Molly (=paymetprovidor)
De procedure zoals hij nu is m.b.t. het aanvragen van een ***** (in Gravity forms):
1. Klant maakt keuze voor letter en nummer
2. Klant kiest of het een aanvraag is voor een
a. Bedrijf
b. Organisatie/vereniging
c. Particulier
3. Klant geeft een eventuele kortingscode in en krijgt direct te zien waar deze kortingscode recht op geeft of bij een onjuiste invoer de melding dat deze code niet bestaat of is verlopen
4. Klant voert basis gegevens in
a. Gegevens aanvrager
b. Gegevens bedrijf/organisatie/vereniging (indien van toepassing)
5. Klant kiest een beveiligingsvraag (noodzakelijk voor het geval hij de autorisatiecode kwijt is)
6. Klant kiest eventueel hoe hij op deze website is gekomen, gaat akkoord met voorwaarden, kiest wel/niet voor digitale ondertekening en komt in de betaalmodule om het depotbedrag te voldoen.
7. Na betaling (en afhankelijk of deze is gelukt) komt de klant terug op de website met specifieke pagina met informatie.
TOELICHTING
- Voor ******NL is het geen probleem af te stappen van Gravity forms en/of Promatic zolang er maar een koppeling met het aanvraagformulier plaatsvindt met Molly als paymentprovidor en er een correctie registratie en terugkoppeling plaatsvindt of de aanvraag is betaald.
- De vraag voor bedrijf/organisatie/particulier is belangrijk ivm met het tonen van verschillende velden. Een particuliere aanvraag hoeft immers geen bedrijfsgegevens in te voeren.
- Kortingcodes zijn dynamisch en moeten een looptijd hebben waarna deze, wanneer ze worden ingevoerd, de melding krijgen dat deze ortingscode is verlopen.
Belangrijk nadat de aanvraag heeft plaatsgevonden:
1. dat er een unieke autorisatiecode wordt gegenereerd (exact 10 karakters - cijfers/letters en alleen hoofdletters).
2. Afhankelijk of er is gekozen voor direct of uitgestelde betaling en digitale of manuele ondertekening van de overeenkomst wordt er een overeenkomst gegenereerd. (Deze blijft in het backend systeem of portal voor de administrator zichtbaar om goed te keuren waarna deze vanuit het portal wordt doorgemaild naar de klant met de algemene voorwaarden en welkomstbrief)
3. Klant ontvangt direct na de aanvraag een bevestiging per e-mail met daarin zijn username (=nummer) en wachtwoord (=random - 12 karakters ) en de URL naar het portal.
Portal
Het portal is een nieuwe toevoeging waarin de klant bepaalde gegevens kan terugzien en aanpassen en waarin de administrator handelingen kan verrichten voor de klant of meerdere klanten tegelijkertijd.
A. Voor de klant
1. Klant MOET na eerste inlog zijn password wijzigen
i. minimaal 12 karakters, 1 hoofdletter, 1 cijfer en 1 karakter
ii. mag niet de autorisatiecode zijn
2. Klant heeft de optie om zijn username te wijzigen
Functionaliteiten van het portal voor de klant (tabs)
1. BASISINSTELLINGEN - De klant kan hierin zijn basis gegevens aanpassen
a. Username (moet na wijziging via mail nogmaals worden bevestigd)
b. Password (moet na wijziging via mail nogmaals worden bevestigd)
c. E-mailadres (moet na wijziging via mail nogmaals worden bevestigd. Ook dient er een melding naar het oude mailadres te worden gestuurd dat het mail adres is gewijzigd)
d. Een aantal ****** instellingen:
i. Geadresseerden (maximaal zijn 4 geadresseerden mogelijk waarbij de naam aanvrager en/of bedrijfsnaam altijd standaard zijn en niet te wijzigen)
ii. Wel of geen verwerking van geadresseerde reclame
iii. Wel of geen ontvangst van postpakketten
iv. Wel of geen ontvangst van aangetekende stukken
v. De keuze van verwerking van inkomende post
1. Per inkomend poststuk afzonderlijk bepalen wat er dient te gebeuren (alle enveloppen worden gescand en klant bepaalt per poststuk wat er verder mee moet gebeuren)
2. Alle inkomende post doorsturen met frequentie van
a. 2 maal per week
b. 1 maal per week
c. 1 maal per 2 weken
d. 1 maal per 4 weken
3. Alle post openen, de inhoud scannen in het portal plaatsen
2. POSTVERWERKING - Wanneer de klant voor optie 1 of 3 heeft gekozen kan hij in het portal op een ander tabblad zijn post inzien en aangeven wat ermee dient te gebeuren. Indien hij voor optie 2 heeft gekozen is zijn 'standaard' keuze op dit tabblad zichtbaar en door hemzelf te wijzigen.
a. Wanneer het een scan van een enveloppe betreft kan hij aangeven of hij deze doorgestuurd, geopend en gescand, vernietigd of bewaard wenst te hebben. (na 7 dagen wordt de status van de enveloppe scan automatisch op bewaren gezet en krijgt de klant hiervan een melding per e-mail)
b. Wanneer het een scan van de inhoud betreft kan hij aangeven of hij deze alsnog doorgestuurd, vernietigd of bewaard wenst te hebben. (na 7 dagen wordt de status van de scan automatisch op bewaren gezet en krijgt de klant hiervan een melding per e-mail).
3. FACTURATIE - De klant kan zijn 4-wekelijkse facturen inzien en downloaden met een geschiedenis van maximaal 1 jaar. Na dit jaar worden de eerste facturen automatisch verwijderd. Indien mogelijk met een voorafgaande waarschuwing aan de klant d.m.v. e-mail.
4. FORMULIEREN
a. Voor het doorgeven van privacy gevoelige gegevens zoals adressen (wijziging woonadres, vestigingsadres, postadres, factuuradres, eenmalig postadres) dient een formulier te komen. ******NL wil geen adresgegevens online bewaren. Voor het doorgeven van deze wijzigingen is na het inloggen additioneel de autorisatiecode nodig. (formulierenfunctie Gravity Forms?)
b. Aanvullen van het depotbedrag. Indien de klant zijn depotbedrag wenst aan te vullen kan dit vanuit het portal dmv de koppeling met de paymentprovidor Molly (formulierenfunctie Gravity Forms?)
c. Opvragen van zijn/haar autorisatiecode. (Indien een klant zijn/haar autorisatiecode is vergeten kan hij deze opvragen middels de beveiligingsvraag waarna deze direct wordt toe gemaild vanuit de database)
d. Ticketsysteem - voor het aangeven van bepaalde zaken, storingen, vragen enz kan een eenvoudig ticketsysteem worden gehanteerd waarbij de klant dus het antwoord op zijn vraag niet krijgt via mail maar kan lezen in zijn eigen portal. Wanneer ******NL een antwoord heeft geplaatst krijgt de klant hiervan automatisch een e-mail (Optioneel door Stric te implementeren. Kan ook gedaan worden door bestaand extern programma of wordpress plugin)
e. Be?indigen van de overeenkomst. Betreffende de mogelijkheid om de overeenkomst met ******NL vanuit de klant eenvoudig te be?indigen kan een formulier volstaan waarin de klant kan vermelden waar het eventuele tegoed kan worden teruggestort. Autorisatiecode is nodig om te be?indigen.
TOELICHTING
- Klant kan de naam van de aanvrager (= een geadresseerde) nimmer wijzigen. Hiervoor dient een nieuwe overeenkomst te worden opgesteld.
- Er dient verder nagedacht te worden op welke manier de aanpassingen van de klant doorgegeven dienen te worden aan de administratie. Als voorzetje.... Voor de administratie is het van minder belang om in het portal zelf de wijzigingen te zien. Wijzigingen dienen namelijk zo snel mogelijk te worden verwerkt voor de fysieke verwerking van de post.
o Indien een klant een mailadres wijzigt is het eenvoudiger om van elke klant afzonderlijk direct na wijziging een e-mail te sturen naar de administratie met de wijziging (nadat de klant een confirmatie- en vervolgens een bevestigingsmail heeft ontvangen)
o Bij een wijziging in een instelling (zoals geadresseerden, reclame, frequentie of soort van verwerking) dient dit in een gestandaardiseerd formulier (PDF) te worden geplaatst welke alle instellingen voor alleen die klant aangeeft. Dit formulier is nodig om te bevestigen aan de daadwerkelijke ******* van de betreffende klant.
- Uploaden van scans - Zoals eerder in de voorbespreking besproken is het een optie om pdf bestanden automatisch te laten uitlezen en te uploaden wanneer in een bepaalde map geplaatst. Indien mogelijk is het dan een optie om de enveloppe scan anders te noemen (en/of in een nadere map) dan de inhoud scans zodat deze ook anders behandeld worden wanneer ge?pload in het portal. Bij een upload van een enveloppe is er immers een optie 'scannen van inhoud' mogelijk. Die is er niet wanneer de inhoud al is gescand.
- Wanneer de status van een gescand stuk in bewaren wijzigt (door klant gekozen of automatisch) ontvangt de klant een e-mail/scherm melding met daarin een nader te bepalen tekst.
- Facturen worden automatisch ge?pload door het systeem en bij de juiste klant geplaatst op basis van bestandsnaam die het *******nummer bevat.
- Van elke scan/pdf upload (enveloppe, inhoud scan en/of factuur) naar het portal ontvangt de klant een automatisch gegenereerd bericht (vanaf het no-reply@******nl.nl) mailadres.
- De layout van het portal is belangrijk en dient gebruiksvriendelijk te worden opgezet. Voordat de programmeur hiermee begint dient hieromtrent eerst overleg plaatst te vinden.
- Het is mogelijk dat er een scan wordt geupload van een enveloppe die bijvoorbeeld een bankpas of pincode bevat. Het moet ingesteld kunnen worden dat de klant deze NIET kan laten openen of vernietigen.
- Indien het een pakket betreft moet de klant kunnen aangeven op welke manier hij dat toegezonden wenst te krijgen (PostNL, UPS ea) met de mogelijkheid de zending wel of niet verzekerd te verzenden en tegen welk bedrag.
Functionaliteiten van het portal voor ******NL
Voor wat betreft de administratie zijn er beperkte functionaliteiten nodig.
- Het downloaden van een excel (of csv) bestand met data (in een bepaalde volgorde)
- De mogelijkheid om een bij een klant bepaalde functionaliteit te blokkeren (inzien van scans, downloaden van geschiedenis, wijzigen van gegevens enz). Redenen van blokkade kunnen zijn:
o Depotbedrag nog niet ontvangen
o Depotbedrag te laag
o Getekende overeenkomst niet ontvangen
o +
Klant dient wel een melding te krijgen waarom account (nog) is geblokkeerd met de oplossing direct daarbij (upload overeenkomst of button naar storting depot)
- De mogelijkheid om alle nummers in rijen te zien met de optie sommigen aan te vinken en een bericht te mailen.
o Deze berichten zijn templates waarin gepersonaliseerde data wordt geplaatst vanuit de database
o Templates zijn eenvoudig met een editor in HTML (ook tabellen) aan te maken, te wijzigen of te verwijderen.
Volgens mij zijn we zo aardig compleet! Daar waar het mogelijk is om van bestaande plugins gebruik te maken of te blijven maken, lijkt ons dat wenselijk. Enerzijds omdat we het wiel opnieuw hoeven uit te vinden en anderzijds om de kosten te drukken. Mochten er vragen hebben hoor ik het graag.
Graag zien we jouw reactie tegemoet.