Så bygger du en kundportal: filer, status, fakturor och behörigheter

En kundportal är ett privat område där var och en av dina kunder loggar in för att se status för sitt projekt, delade filer, öppna ärenden och fakturor. För att bygga en behöver du definiera exakt vad en kund behöver se under de första tio sekunderna, modellera kunder, projekt och filer så att varje post tillhör en kund, säkerställa på servern att kunder bara ser sina egna poster, och hålla uppladdningar i privat lagring. Funktionslistan kan vara kort; det som betyder mest är att behörigheterna är rätt.

Varför företag bygger kundportaler

Portaler ersätter oftast en hög e-posttrådar, delade mappar och "vad är status?"-meddelanden. Byråer, revisorer, konsulter, byggföretag, studior och tjänsteföretag använder alla portaler. En bra portal:

• Besvarar statusfrågan innan kunden ställer den.
• Samlar filer på ett ställe, med den senaste versionen tydlig.
• Ger förfrågningar ett eget hem i stället för spridda e-postmeddelanden.
• Gör att du ser organiserad ut, vilket spelar roll för kundbehållning och hänvisningar.

Om du har en eller två kunder och inget känsligt kan ett delat dokument eller en mapp räcka. En portal är värd att bygga när du har många kunder, återkommande uppdrag, eller information som kunder inte bör se om varandra.

Vad en kundportal behöver

Börja med inloggning, översikt, filer och förfrågningar. Lägg till fakturor, godkännanden och meddelanden när kunderna faktiskt behöver dem.

Datan

En typisk portal har: kunder (företag), kundanvändare (personer som loggar in, och hör till en kund), dina teammedlemmar, projekt (som hör till en kund), milstolpar eller statusuppdateringar, filer (som hör till ett projekt), förfrågningar och eventuellt fakturor. Den viktiga designregeln: varje post bör kunna spåras tillbaka till exakt en kund. Då är behörigheterna enkla att säkerställa och kontrollera.

Behörigheter

Skriv ner dessa och testa dem:

• En kundanvändare ser bara projekt, filer, förfrågningar och fakturor som hör till deras kund.
• Interna anteckningar visas aldrig för kunder.
• Teammedlemmar ser de kunder de är tilldelade, eller alla kunder om ni är små.
• Filländar är privata och tidsbegränsade, inte publika URL:er som vem som helst kan dela eller gissa.
• Att ta bort en kundanvändare tar omedelbart bort deras åtkomst.

Kontrollerna måste ske på servern. En portal som laddar alla kunders data och filtrerar den i webbläsaren är inte privat.

Beslut och avvägningar

Inloggningsmetod

Kunder loggar in sällan, så de glömmer lösenord. Magiska länkar (en inloggningslänk skickad via e-post) eller enkel inloggning med ett konto de redan använder fungerar ofta bättre än lösenord för portaler. Oavsett vad du väljer, bjud in kunder från din sida i stället för att låta vem som helst registrera sig. Vår guide om hur du lägger till inloggning i din app jämför alternativen.

En portal eller en per kund

En app med en kundlista är enklare att underhålla än en separat sajt per kund. Du kan fortfarande ge varje kund en egen varumärkesprofil – sin logotyp, sina projektnamn – inom samma app.

Filer

Använd riktig fillagring i stället för att spara uppladdningar på serverns egna disk, sätt en maximal filstorlek, begränsa filtyper om du kan, och servera bara filer till användare som klarar behörighetskontrollen. Bestäm hur versioner fungerar: skriva över, eller spara historik.

Fakturor och betalningar

Du kan visa fakturor från ditt bokföringsverktyg, skapa enkla fakturor i portalen, eller länka till en hostad betalningssida. Att bygga ett fullständigt faktureringssystem är ett projekt för sig – se hur du bygger en faktureringsapp. För en portal räcker oftast att visa fakturastatus och en "Betala nu"-länk till en hostad kassa.

Integrationer

Många portaler hämtar status från verktyg du redan använder – ett projektverktyg, ett CRM eller bokföringsprogram – i stället för att du måste uppdatera två ställen. Integrationer sparar tid men lägger till installation och underhåll. Om ditt team redan arbetar i ett CRM kan du överväga att bygga portalen ovanpå samma data.

En första prompt för en AI-byggare

Bygg en kundportal för Northlight, en liten webbdesignbyrå. Kunder är företag; varje har en eller flera kundanvändare som loggar in. Kundanvändare ser bara sitt eget företags projekt. För varje projekt: nuvarande status (Förstudie, Design, Bygge, Granskning, Live), nästa milstolpe med datum, ett filområde där båda sidor kan ladda upp och ladda ner (PDF, bilder, ZIP, max 50 MB), ett förfrågningsformulär (titel, detaljer, prioritet) med en lista över deras tidigare förfrågningar och status, och en tidslinje över uppdateringar. Byråns personal ser en administrationsyta med alla kunder, kan ändra projektstatus, skriva uppdateringar, lägga till interna anteckningar som kunderna aldrig ser, och besvara förfrågningar. Tillämpa alla åtkomstregler på servern. Spara data i en databas och filer i privat fillagring med tidsbegränsade nedladdningslänkar. Platshållarinloggning tills vidare – vi lägger till riktig autentisering härnäst. Ren, professionell design som fungerar på telefoner.

Bygg i steg: data och administration först, sedan kundvyn, sedan riktig inloggning, sedan filer, sedan extrafunktioner. Hur man skriver prompter för AI-appbyggare har fler mönster.

Byggsteg

1. Lista vad en kund behöver se först, och vad de för närvarande mejlar dig om.
2. Designa datan så att varje post tillhör en kund.
3. Bygg administrationsvyn och lägg in en riktig kunds data.
4. Bygg kundvyn för den kunden.
5. Lägg till riktig inloggning med inbjudningar från din sida.
6. Lägg till filer i privat lagring med behörighetskontroller vid nedladdning.
7. Testa behörigheterna: skapa två testkunder och försök alla sätt att se den andras data – ändra ID:n i URL:en, gissa fillänkar, använda en gammal inbjudan.
8. Lägg till förfrågningar och aviseringar via e-post.
9. Pilotera med en eller två vänliga kunder och fråga vad de fortfarande mejlar dig om.
10. Lägg till fakturor, godkännanden eller integrationer utifrån den återkopplingen.

Vanliga misstag

• Filtrering i webbläsaren i stället för på servern. Det allvarligaste felet i en portal: varje kunds data laddas ner, bara dold.
• Publika filadresser. En delad länk som vem som helst kan öppna gör portalen meningslös.
• Öppen registrering. Kunder bör bjudas in, inte kunna skapa egna konton och välja företag.
• För många funktioner vid lansering. En portal som kunderna inte förstår ignoreras till förmån för e-post.
• Två sanningskällor. Om status finns i ditt projektverktyg och i portalen blir en av dem inaktuell. Välj en eller synkronisera dem.
• Att glömma avvecklingen. När en kunds personal slutar måste deras åtkomst upphöra.
• Att lagra reglerad data utan rätt skydd. Hälso-, juridiska eller ekonomiska handlingar kan medföra lagkrav du måste uppfylla.

Kostnader och verktyg

De löpande kostnaderna är hosting, en databas, fillagring (som växer med de filer du delar) och en e-postleverantör för inbjudningar och aviseringar. Om du använder en hostad inloggningstjänst eller betalningsleverantör, kontrollera deras aktuella priser på deras egna sajter. Jämfört med portalprogram med avgift per användare växer kostnaderna för din egen portal med användningen i stället för med antalet kunder.

När en färdig produkt är det bättre valet

Program för kundportaler, och portalfunktioner inbyggda i bokförings-, juridiska eller byråadministrativa verktyg, kan vara det bättre valet när din bransch har särskilda krav – e-signaturer med juridisk giltighet, reglerad dokumenthantering, utbyte av skatteunderlag – eller när ditt befintliga verktyg redan har en portal. De produkterna har redan hanterat efterlevnad och support. Bygg din egen när ditt arbetsflöde inte passar generiska portaler, när du vill att portalen ska matcha ditt varumärke och din process exakt, eller när pris per kund eller per användare inte längre är rimligt för dig.

Bygga den med Mythex

Mythex kan bygga portalen i prompten ovan: en kundvy, en administrationsvy, förfrågningar och en tidslinje, med en dedikerad Postgres-databas och fillagring som läggs till när appen behöver dem. Kundinloggning är medbringa-själv – Mythex-konton är för dem som bygger appen, och du väljer en autentiseringsmetod för dina kunder som agenten kopplar in. Mythex har ingen inbyggd e-signatur- eller faktureringsprodukt, så de är integrationer eller funktioner du bygger. Använd projekthemligheter för alla API-nycklar, och testaren för appen i chatten för att klicka igenom kund- och administrationsflödena innan du publicerar.

Dokumentationen har ett användningsfall för kundportal och täcker fillagring och att lägga till inloggning. Som startprompt, prova mallen kundportal för byrå eller bläddra bland appmallar. Innan du bjuder in riktiga kunder, gå igenom vår säkerhetschecklista för AI-byggda appar.

Frågor