When a form should become a portal

Most B2B sites have a form because it felt finished. A field, a button, a thank-you page, a mail to a shared inbox. That is the right answer to a first-time question: "can you do this?", "send a catalogue", "book a meeting". It is the wrong answer the day the same person has a case that lives longer than the inbox SLA.

Then the shadow system starts. A sheet with columns someone invented on a Tuesday. A Slack thread that is the truth until it scrolls away. A salesperson who promises "I'll chase it", without the customer being able to see whether anyone did. The form is still green in your CMS. The process is red. That is what people mean by self-serve, without needing a product with roles and invoices.

Teams over-build or under-build. Over: a portal project with SSO, a branded app and a roadmap that looks like an ERP, because someone said "customers should be able to log in". Under: another Typeform, a nicer notification, a hope that the inbox will be read this time. Both miss the threshold. The threshold is whether the customer has a place to see the state without asking a human who first has to ask another human.

We write this because "customer form" and "customer portal" get used as synonyms in RFPs, and as enemies in workshops. They are a spectrum. Your job is to point at where you are, and to build the next cut — not to buy a login because a competitor's site has one.

A form is a structured email. It is done when the message has arrived, and you have what you need to reply once. Contact. Newsletter. A one-off quote. An application where the rest lives in an ATS you already have. If the case dies in the first reply, or moves into a real system immediately, do not build a portal in front. Make the form honest: fewer fields, the right destination, a receipt that does not lie.

It is also enough when volume is low and the people who reply are the people who know. Three enquiries a week that the founder handles are not a product problem. They are a calendar. A portal here is theatre: you built a login for a queue that does not exist, and you gave yourselves a new system to forget to update.

It stops being enough when the message has an afterlife. "How far are you?" "Do you still need something from us?" "We sent it on Monday — did you get it?" That is not a copy problem on the thank-you page. It is a missing object: a request with an id, a state, and a person who is allowed to see it. Without the object, every follow-up is a new form, or a mail you dig out.

Notice what you should not wait for. Do not wait for an ERP. Do not wait until "all customers" want self-serve. Wait for — or rather: count — the repetition. If the same case generates more than one human status-touch, the form has become a ticket system you refuse to name.

Login is the worst signal you can steer by. A login is expensive: forgotten passwords, invites, who may see what, what happens when the person changes jobs. It is the right call when the same person comes back to the same objects over months — orders, contracts, cases. It is the wrong call when you really need them to open one link and see "received / missing file / in progress / done".

That is why the honest middle step is often a magic link or a case number plus an email you already have. No account. No "customer universe". A page that shows the state of that one request, and a mail when the state changes. That is self-serve. It is not the portal an RFP describes. It stops the phone more often than a roadmap with roles.

The full portal — organisation, several users, documents, orders — is the next cut, when the same login has to carry more than one case, and when permissions start to matter. That is the customer-portal post's territory. Do not confuse the two, so you either build a product for a form, or stay in the inbox long after you have 200 open cases in a sheet.

No-code can be the middle step. A tool that gives you an id, a status and a customer-facing page beats a custom build you will not own. It stops beating that when you start mirroring your real rules in Zapier snakes: different SLAs, files that must not sit in the wrong workspace, a customer who must not see someone else's case. Then you are back at the threshold in the portal post. Here, in the form post, the test is still: can the customer see their own state without asking you?

An honest v1 at this threshold is boring, and that is the point. A request with an id. Three to five states you dare say out loud. A page behind a link. A mail on change. An internal view that is the same object — not a sheet beside it. On Next.js that is a few screens and a table. It is not "the customer at the centre". It is stopping the lie that the mail was the system.

You should bind it to what you already have, without waiting for the big integration. A CSV or a manual status you set when you actually touched the case beats a "full Salesforce sync" you do not have data for. Portals die from promising ERP truth and delivering an empty dashboard. A form follow-up dies of the same thing, just earlier.

What you should not build in this cut: a universal inbox product, chat, a forum, a document archive "while we are in there anyway". Each extra object is a new place the truth can happen. Keep the object to the request the phone rings about. When it rings about something else — an invoice, a contract — you are out of this article and into a real portal.

No-code versus custom is the usual choice. A tool with portal skin is fine until the rules are yours. Custom is right when the link, the state and the isolation are the product — not when you are tired of Typeform. Tiredness is not an architecture. Repetition and a sheet the customer must not see are.