Ontwikkeling van een klantportaal: wanneer u zelf bouwt versus een kant-en-klaar oplossing koopt
Een klantportaal is een besloten ruimte waar uw klanten of partners de status van hun werk kunnen zien, bestanden kunnen uploaden en downloaden, documenten kunnen ondertekenen en soms facturen kunnen betalen. De meeste teams zien het als een leuke toevoeging. In werkelijkheid vermindert een werkend portaal de rommel in uw inbox, voorkomt het dat klanten twee keer dezelfde vraag stellen, en verwijdert het de wrijving van e-mailbijlagen en handmatige vervolgacties.
De vraag is niet of u er een nodig hebt. De vraag is of een kant-en-klaar portaalproduct het werk kan doen, of dat op uw workflow afgestemde klantportalontikkeling de moeite waard is.
Wat een kant-en-klaar portaal doet
Standaard portaalsoftware is gebouwd voor een generieke workflow. Een klant meldt zich aan, ziet een projectdashboard, uploadt bestanden naar een map, downloadt deliverables en ondertekent mogelijk een document of betaalt een factuur via een ingebedde betalingslink. De installatie is snel. De kosten zijn voorspelbaar. U hebt geen ontwikkelaar nodig.
Dit werkt goed als uw workflow overeenkomt met de sjabloon. Als uw klanten een Gantt-diagram moeten zien, mijlpalen in een specifieke volgorde moeten goedkeuren, of automatische meldingen moeten ontvangen wanneer een taak naar het volgende stadium gaat, kan een kant-en-klaar portaal dit waarschijnlijk doen. Als uw portaal gegevens moet ophalen uit uw boekhoudingsoftware, uw CRM of uw projectmanagementtool en deze live moet weergeven, kunnen de meeste standaardportalen integreren met veelgebruikte platforms via vooraf gebouwde connectoren.
Het probleem is dat standaardportalen zijn ontworpen voor het meest voorkomende geval. Ze werken het best wanneer u uw proces in hun proces kunt passen, niet andersom.
Wanneer kant-en-klaar niet volstaat
Drie situaties maken kant-en-klaar portalen vaak een slechte keuze.
Ten eerste is uw workflow ongebruikelijk. Misschien moeten uw klanten werk in fasen goedkeuren, en goedkeuring van de ene klant triggert een taak voor een ander. Misschien moet u verschillende gegevens tonen aan verschillende gebruikersrollen binnen dezelfde klantaccount. Misschien moet u een reeks stappen afdwingen die de portaalsoftware niet is gebouwd om af te dwingen. Standaardsoftware biedt instellingen en schakelaars, maar heeft grenzen.
Ten tweede moet uw portaal communiceren met systemen die de leverancier van de kant-en-klaar oplossing niet ondersteunt. U kunt een niche-boekhoudingspakket gebruiken, een aangepaste CRM of interne tools die uw team jaren geleden heeft gebouwd. Het portaal moet live gegevens uit deze systemen ophalen en soms gegevens terugschrijven. Als de leverancier geen integratie biedt, zit u vast.
Ten derde verwachten uw klanten dat het portaal aanvoelt als onderdeel van uw merk en uw service, niet als een tool van derden waartoe zij toevallig toegang hebben. Dit is moeilijker te meten maar wel echt. Een portaal dat eruitziet en aanvoelt als uw website, uw terminologie gebruikt en uw exacte workflow volgt, geeft het signaal dat u hun ervaring goed hebt doordacht. Een kant-en-klaar portaal, hoe schoon ook, geeft het signaal dat u een sjabloon hebt gekocht.
Wanneer aangepaste klantportalontikkeling zinvol is
Als een of meer van die drie situaties op u van toepassing zijn, is klantportalontikkeling het overwegen waard. Een aangepast portaal is gebouwd om in uw workflow te passen, niet andersom. Het integreert met de systemen die u werkelijk gebruikt. Het ziet er uit en voelt aan als uw service.
De afweging is tijd en kosten. Een aangepast portaal duurt langer om te bouwen dan zich aanmelden voor een SaaS-product. U moet ook beslissen wie het host en beheert. Sommige teams willen het zelf beheren. Anderen geven dit liever over aan het bureau dat het heeft gebouwd, zodat zij geen servers, updates of back-ups hoeven te beheren.
Waarom standaard projectcontrolesoftware SaaS niet aansluit voor groeiende teams behandelt dezelfde spanning in een ander verband. De onderliggende vraag is dezelfde: past een sjabloonproduct in uw werkelijke proces, of hebt u iets nodig dat voor u is gebouwd?
Nog één ding: e-handtekeningen
Veel portalen bevatten een functie voor documentondertekening. Als uw portaal handtekeningen nodig heeft, hebt u opties. Sommige kant-en-klaar portalen bevatten e-handtekening als ingebouwde functie. Anderen vereisen dat u een aparte e-handtekeningsleverancier gebruikt. Als u een aangepast portaal bouwt, kunt u ondertekening erin bouwen of het verbinden met een e-handtekeningsservice van derden.
Upward Technologies bouwt aangepaste portalen en biedt ook DocSign, zijn eigen e-handtekeningsproduct, dat in een portaal kan worden ingebed of zelfstandig kan worden gebruikt.
Hoe u beslist
De eerste stap is het in kaart brengen van uw werkelijke workflow. Wat moet een klant doen? In welke volgorde? Welke systemen moeten gegevens in het portaal invoeren? Wat moet de klant zien dat uniek is voor uw bedrijf?
Zodra u die kaart hebt, kunt u deze testen tegen een kant-en-klaar product. Als het product het kan doen zonder zware workarounds, koop het product. Als u merkt dat u zegt "we zouden moeten veranderen hoe we werken," is dat een signaal dat aangepaste ontikkeling misschien de betere weg is.
Als u onzeker bent, is een betaalde scopingfase van drie weken een praktische manier om erachter te komen. Upward Technologies voert een scopingfase uit voordat enige bouw begint. Het eindigt met een document dat laat zien hoe een aangepast portaal eruit zou zien, hoe het zou werken en of het de moeite waard is om te bouwen. U kunt dan beslissen of u doorgaat of in plaats daarvan een kant-en-klaar optie kiest.
