Slik bygger du en klientportal: filer, status, fakturaer og tilganger

En klientportal er et privat område der hver av kundene dine logger inn for å se status på prosjektet, delte filer, åpne forespørsler og fakturaer. For å bygge en må du definere nøyaktig hva en kunde må se i løpet av de første ti sekundene, modellere kunder, prosjekter og filer slik at hver post hører til én kunde, håndheve på serveren at kunder bare ser sine egne poster, og holde opplastinger i privat lagring. Funksjonslisten kan være kort. Det som betyr noe er å få tilgangene riktige.

Hvorfor bedrifter bygger klientportaler

Portaler erstatter vanligvis en haug med e-posttråder, delte mapper og meldinger om «hva er status?». Byråer, regnskapsførere, konsulenter, entreprenører, studioer og tjenestebedrifter bruker dem alle. En god portal:

• Svarer på statusspørsmålet før kunden stiller det.
• Samler filene på ett sted, med tydelig siste versjon.
• Gir forespørsler et skikkelig hjem i stedet for spredte e-poster.
• Gjør at du fremstår organisert, noe som betyr noe for kundelojalitet og anbefalinger.

Hvis du har en eller to kunder og ingenting sensitivt, kan et delt dokument eller en mappe være nok. En portal er verdt å bygge når du har mange kunder, gjentakende arbeid, eller informasjon kundene ikke skal se om hverandre.

Hva en klientportal trenger

Start med innlogging, oversikt, filer og forespørsler. Legg til fakturaer, godkjenninger og meldinger når kundene faktisk trenger dem.

Dataene

En typisk portal har: kunder (firmaer), kundebrukere (personene som logger inn, som hører til én kunde), dine teammedlemmer, prosjekter (som hører til én kunde), milepæler eller statusoppdateringer, filer (som hører til et prosjekt), forespørsler, og eventuelt fakturaer. Den viktigste designregelen: hver post må kunne spores tilbake til nøyaktig én kunde. Da blir tilganger enkle å håndheve og å kontrollere.

Tilganger

Skriv disse ned og test dem:

• En kundebruker ser bare prosjekter, filer, forespørsler og fakturaer som hører til deres kunde.
• Interne notater vises aldri til kunder.
• Teammedlemmer ser kundene de er tildelt, eller alle kunder hvis dere er små.
• Fillenker er private og tidsbegrensede, ikke offentlige URL-er som noen kan dele eller gjette.
• Når en kundebruker fjernes, mister vedkommende tilgangen umiddelbart.

Sjekkene må skje på serveren. En portal som laster alle kunders data og filtrerer dem i nettleseren er ikke privat.

Avgjørelser og avveininger

Innloggingsmetode

Kunder logger sjelden inn, så de glemmer passord. Magiske lenker (en innloggingslenke sendt på e-post) eller single sign-on med en konto de allerede bruker, fungerer ofte bedre enn passord for portaler. Uansett valg bør du invitere kunder fra din side i stedet for å la hvem som helst registrere seg. Vår guide om hvordan du legger til innlogging i appen din sammenligner alternativene.

Én portal eller én per kunde

Én app med en kundeliste er enklere å vedlikeholde enn et eget nettsted per kunde. Du kan likevel gi hver kunde en egen merkevarefølelse, med logoen deres og prosjektnavnene deres, innenfor samme app.

Filer

Bruk ordentlig fillagring i stedet for å lagre opplastinger på serverens egen disk. Sett en maksimal filstørrelse, begrens filtyper hvis du kan, og server filer bare til brukere som består tilgangssjekken. Bestem hvordan versjoner fungerer: overskriving, eller å beholde historikk.

Fakturaer og betalinger

Du kan vise fakturaer fra regnskapsverktøyet ditt, lage enkle fakturaer i portalen, eller lenke til en hostet betalingsside. Å bygge et fullverdig faktureringssystem er et prosjekt for seg selv. Se hvordan du bygger en fakturaapp. For en portal er det vanligvis nok å vise fakturastatus og en «Betal nå»-lenke til en hostet betalingsside.

Integrasjoner

Mange portaler henter status fra verktøy du allerede bruker, som et prosjektverktøy, et CRM eller regnskapsprogramvare, i stedet for at du må oppdatere to steder. Integrasjoner sparer tid, men gir oppsett og vedlikehold. Hvis teamet ditt allerede jobber i et CRM, bør du vurdere å bygge portalen på toppen av de samme dataene.

En første prompt til en AI-bygger

Bygg en klientportal for Northlight, et lite webdesignbyrå. Kunder er firmaer; hver har én eller flere kundebrukere som logger inn. Kundebrukere ser bare sitt eget firmas prosjekter. For hvert prosjekt: nåværende status (Utforsking, Design, Bygging, Gjennomgang, Live), neste milepæl med dato, et filområde der begge sider kan laste opp og laste ned (PDF, bilder, ZIP, maks 50 MB), et forespørselsskjema (tittel, detaljer, prioritet) med en liste over tidligere forespørsler og status, og en tidslinje over oppdateringer. Byråets ansatte har et administrasjonsområde med alle kunder, kan endre prosjektstatus, legge inn oppdateringer, legge til interne notater som kundene aldri ser, og besvare forespørsler. Håndhev alle tilgangsregler på serveren. Lagre data i en database og filer i privat fillagring med tidsbegrensede nedlastingslenker. Foreløpig plassholderinnlogging. Vi legger til ekte autentisering senere. Rent, profesjonelt design som fungerer på telefoner.

Bygg i steg: data og administrasjon først, deretter kundevisningen, så ekte innlogging, filer og tillegg. Hvordan skrive prompter til AI-appbyggere har flere mønstre.

Byggesteg

1. List opp hva en kunde trenger å se først, og hva de i dag sender e-post om.
2. Design dataene slik at hver post hører til én kunde.
3. Bygg administrasjonsvisningen og legg inn en reell kundes data.
4. Bygg kundevisningen for den kunden.
5. Legg til ekte innlogging med invitasjoner fra din side.
6. Legg til filer i privat lagring med tilgangssjekker ved nedlasting.
7. Test tilgangene: lag to testkunder og prøv alle måter å se den andres data på: endre ID-er i URL-en, gjette fillenker, bruke en gammel invitasjon.
8. Legg til forespørsler og varsler på e-post.
9. Pilot med en eller to vennlige kunder og spør hva de fortsatt sender deg e-post om.
10. Legg til fakturaer, godkjenninger eller integrasjoner basert på den tilbakemeldingen.

Vanlige feil

• Filtrering i nettleseren i stedet for på serveren. Den alvorligste feilen i en portal: alle kunders data lastes ned, de bare skjules.
• Offentlige filadresser. En delelenke som hvem som helst kan åpne, ødelegger hele portalen.
• Åpen registrering. Kunder bør inviteres, ikke kunne opprette egne kontoer og velge firma selv.
• For mange funksjoner ved lansering. En portal kundene ikke forstår, blir ignorert til fordel for e-post.
• To kilder til sannhet. Hvis status ligger i prosjektverktøyet ditt og i portalen, vil den ene bli utdatert. Velg én, eller synkroniser dem.
• Å glemme avslutning. Når en ansatt hos kunden slutter, må tilgangen deres opphøre.
• Å lagre regulerte data uten riktig beskyttelse. Helse-, juridiske eller økonomiske opplysninger kan ha lovkrav du må oppfylle.

Kostnader og verktøy

De løpende kostnadene er hosting, en database, fillagring (som vokser med filene dere deler), og en e-postleverandør for invitasjoner og varsler. Hvis du bruker en hostet innloggingsleverandør eller betalingsleverandør, sjekk gjeldende priser på deres egne nettsider. Sammenlignet med programvare for portaler med priser per plass, vokser kostnadene for din egen portal med bruken i stedet for med antall kunder.

Når et ferdig produkt er det bedre valget

Programvare for klientportaler, og portalfunksjoner i regnskaps-, juridiske eller praksisadministrasjonsverktøy, kan være det bedre valget når bransjen din har spesifikke krav, for eksempel elektroniske signaturer med juridisk gyldighet, regulert journalføring eller utveksling av skattedokumenter, eller når verktøyet du allerede bruker inkluderer en portal. Disse produktene har allerede håndtert etterlevelse og støtte. Bygg din egen når arbeidsflyten din ikke passer generiske portaler, når du vil at portalen skal samsvare nøyaktig med merkevaren og prosessen din, eller når pris per kunde eller per plass ikke lenger gir mening for deg.

Bygge det med Mythex

Mythex kan bygge portalen i prompten over: en kundevisning, en administrasjonsvisning, forespørsler og en tidslinje, med en dedikert Postgres-database og fillagring lagt til når appen trenger det. Innlogging for kundene er tatt med selv. Mythex-kontoer er for dem som bygger appen, og du velger en autentiseringsmetode for kundene dine som agenten kobler inn. Mythex har ingen innebygd e-signatur eller fakturering, så disse er integrasjoner eller funksjoner du bygger selv. Bruk prosjekthemmeligheter for eventuelle API-nøkler, og den innebygde app-testeren i chatten for å klikke deg gjennom kunde- og administrasjonsflytene før du publiserer.

Dokumentasjonen har et brukstilfelle for klientportaler og dekker fillagring og å legge til innlogging. Som utgangspunkt for en prompt kan du prøve byrå-klientportal-malen eller bla gjennom appmalene. Før du inviterer ekte kunder, gå gjennom sikkerhetssjekklisten for AI-bygde apper.

Spørsmål