Hvornår en formular skal blive en portal

De fleste B2B-sites har en formular, fordi det føltes færdigt. Et felt, en knap, en tak-side, en mail til en fælles indbakke. Det er det rigtige svar på et førstegangsspørgsmål: "kan I det her?", "send et katalog", "book et møde". Det er det forkerte svar, den dag den samme person har en sag, der lever længere end svartiden i indbakken.

Så begynder skyggesystemet. Et sheet med kolonner, nogen fandt på en tirsdag. En Slack-tråd der er sandheden indtil den scroller væk. En sælger der lover "jeg rykker", uden at kunden kan se, om der blev rykket. Formularen er stadig grøn i jeres CMS. Processen er rød. Det er det, folk mener, når de siger selvbetjening, uden at de har brug for et produkt med roller og fakturaer.

Teams overbygger eller underbygger. Over: et portalprojekt med SSO, brandet app og et roadmap, der ligner et ERP, fordi nogen sagde "kunderne skal kunne logge ind". Under: endnu et Typeform, en bedre notifikation, et håb om at indbakken denne gang bliver læst. Begge misser tærsklen. Tærsklen er, om kunden har et sted at se tilstanden uden at spørge et menneske, der først skal spørge et andet menneske.

Vi skriver det, fordi "kundeformular" og "kundeportal" bliver brugt som synonymer i udbud, og som fjender i workshops. De er et spektrum. Jeres job er at pege på, hvor I er, og at bygge det næste snit — ikke at købe et login, fordi konkurrentens site har et.

En formular er et structured email. Den er færdig, når beskeden er fremme, og I har det I skal bruge for at svare én gang. Kontakt. Nyhedsbrev. Et one-off tilbud. En ansøgning, hvor resten lever i et ATS, I allerede har. Hvis sagen dør i første svar, eller flytter ind i et rigtigt system med det samme, skal I ikke bygge en portal foran. I skal gøre formularen ærlig: færre felter, rigtig destination, en kvittering der ikke lyver.

Den er også nok, når volumen er lav, og de mennesker der svarer, er de samme der ved. Tre henvendelser om ugen, som stifteren selv tager, er ikke et produktproblem. Det er en kalender. En portal her er teater: I har bygget et login til en kø, der ikke findes, og I har givet jer selv et nyt system at glemme at opdatere.

Den holder op med at være nok, når beskeden har et efterliv. "Hvor langt er I?" "Mangler I noget fra os?" "Vi sendte den mandag — fik I den?" Det er ikke et copy-problem på tak-siden. Det er et manglende objekt: en anmodning med et id, en tilstand og en person der må se den. Uden objektet er hvert opfølgende spørgsmål en ny formular, eller en mail I graver frem.

Læg mærke til, hvad I ikke skal vente på. I skal ikke vente på et ERP. I skal ikke vente på, at "alle kunder" vil have self-service. I skal vente på — eller rettere: I skal tælle — gentagelsen. Hvis den samme sag genererer mere end ét menneskeligt status-touch, er formularen blevet et ticket-system, I nægter at navngive.

Login er det dårligste signal, I kan styre efter. Et login er dyrt: glemt kode, invites, hvem der må se hvad, hvad der sker når personen skifter job. Det er det rigtige, når den samme person kommer tilbage til de samme objekter over måneder — ordrer, kontrakter, sager. Det er det forkerte, når I egentlig har brug for, at de kan åbne ét link og se "modtaget / mangler fil / i gang / færdig".

Derfor er det ærligt midttrin ofte et magic link eller et sagsnummer plus en mail, I allerede har. Ingen konto. Ingen "kundeunivers". En side der viser tilstanden på den ene anmodning, og en mail når tilstanden skifter. Det er selvbetjening. Det er ikke den portal, et udbud beskriver. Det stopper telefonen oftere end et roadmap med roller.

Den fulde portal — organisation, flere brugere, dokumenter, ordrer — er det næste snit, når det samme login skal bære mere end én sag, og når rettigheder begynder at betyde noget. Det er kundeportal-postens territorium. Forveksl ikke de to, så I enten bygger et produkt til en formular, eller bliver i indbakken længe efter at I har 200 åbne sager i et sheet.

No-code kan være midttrinnet. Et værktøj der giver et id, en status og en kundevendt side, slår et custom-build, I ikke vil eje. Det holder op med at slå, når I begynder at spejle jeres rigtige regler i Zapier-slanger: forskellige SLA'er, filer der ikke må ligge i det forkerte workspace, en kunde der ikke må se en andens sag. Så er I tilbage ved tærsklen i portal-posten. Her, i formular-posten, er testen stadig: kan kunden se sin egen tilstand uden at spørge jer?

Et ærligt v1 på den her tærskel er kedeligt, og det er meningen. En anmodning med et id. Tre til fem tilstande, I tør sige højt. En side bag et link. En mail ved skift. Et internt view, der er det samme objekt — ikke et sheet ved siden af. På Next.js er det et par skærme og en tabel. Det er ikke "kunden i centrum". Det er at stoppe med at lyve om, at mailen var systemet.

I skal binde det til det, I allerede har, uden at vente på den store integration. En CSV eller en manuel status, I sætter når I faktisk har rørt sagen, slår en "fuld Salesforce-sync", I ikke har data til. Portaler dør af at love ERP-sandhed og levere et tomt dashboard. En formular-efterfølger dør af det samme, bare tidligere.

Det I ikke skal bygge i det snit: et universelt indbakke-produkt, chat, et forum, et dokumentarkiv "mens vi alligevel er i gang". Hvert ekstra objekt er et nyt sted, sandheden kan ske. Hold objektet til den anmodning, telefonen ringer om. Når den ringer om noget andet — en faktura, en kontrakt — er I ude over den her artikel og inde i en rigtig portal.

No-code og custom er det sædvanlige valg. Et værktøj med portal-skin er fint, indtil reglerne er jeres. Custom er rigtigt, når linket, tilstanden og isolationen er produktet — ikke når I er trætte af Typeform. Træthed er ikke en arkitektur. Gentagelse og et sheet, kunden ikke må se, er.