Customer portal with or without registration

“Should customers register?” sounds like a configuration question. It is in fact the decision that determines how many requests you actually receive. One more account to create, at the exact moment somebody has a problem, is where a share of people give up and go back to emailing whoever they happen to know.

Both models exist and neither is right in the abstract. This guide puts the benefits and the risks of each side by side, and ends with a quick way to decide.

The two models, spelled out

They are worth naming properly, because in practice they get mixed up.

• A portal with accounts. Whoever writes must exist before writing: a user, created by you or by them, and a way back in. In exchange they find their own requests again, they can see their company’s history, and you always know who you are talking to.
• A request without an account. There is a form open to anyone. The person leaves a name, an address and a description, and follows that single request from a private link sent to their inbox. No user is created, so there is nothing to remember.

Almost every organisation that gets this right uses both: accounts for the handful of contacts who write every week, an open form for everyone else. The real question is not “which one”, it is “who do I ask an account from, and why”.

What an account actually gives you

An account brings four things, and they are worth separating from the benefits habitually attributed to it.

• History. Whoever signs in sees all of their requests, not only today’s. It is the most concrete benefit, and it matters most to people who open many.
• Identity. You know that this person is this person, and that they work for that company. Under a support contract that is a requirement, not a convenience.
• Permissions. With an account you can decide what that person sees: only their own requests, or their colleagues’ too.
• Continuity. Someone who changes email address remains the same person in your records, with their past attached.

What an account does not bring, although it is often assumed: it does not make requests more complete, it does not reduce duplicates, and it does not stop anyone from emailing you anyway. Anyone expecting those three effects will be disappointed.

What it costs, and who pays it

The cost of registration is not paid by you. It is paid by the person with the problem, at the worst possible moment — and it can be measured.

A request almost always comes from someone annoyed and in a hurry. If at that moment they must create access, wait for a confirmation message, choose credentials, remember them, and then find them again six months later for the next request, a share of those people never reach the end. They do not complain: they write to the salesperson they know, or they phone, and the request returns to the channel you were trying to leave.

Two more costs land on you. The first is abandoned accounts: after two years you have hundreds that were never used again, each holding personal data, which is a retention problem before it is a tidiness problem. The second is access support: a non-trivial share of your requests will be “I can’t sign in”, which is support you are providing on your own portal instead of on your work.

How a portal without accounts works

The model without accounts holds on one condition: the email address must be verified. Without that step anyone could open requests in someone else’s name and, worse, read the replies meant for them.

So the flow that works is always the same: a public form, a message confirming the address really belongs to the sender, and from then on a private link from which that person reads and replies — on that request only, with no password to choose. The operational detail of that flow is told in full in the guide on customer support without customer accounts; what matters here is what you gain and what you give up.

The risks of the no-account model

They are real, and they belong on the table — otherwise the choice is an act of faith.

• The link is the key. Whoever can read that person’s mailbox can reach the request. It is the same level of risk as any password reset, but it should be stated rather than implied.
• One problem, three requests. With no history in front of them, people open a new request instead of replying to yesterday’s. It is manageable, but it must be managed.
• An address is not a company. If you must know for certain that the sender works for that client, an address alone does not prove it; the domain suggests it, and not always.
• An open form also receives noise. You need at least some protection against automated submissions, or you will close it within a month.

How to choose, in five minutes

Three questions, and the answer arrives on its own.

1. How many requests does the typical person open in a year? One or two: do not ask them for an account. One a month: give them one, but create the user yourself rather than making them register.
2. Do you need certainty about who they are? If support is contractual and replies contain confidential information, yes — and the account stops being an obstacle: it becomes a requirement.
3. Must colleagues see each other’s requests? If a contact needs to read what their colleagues opened, you need accounts: without identity there is no honest way to decide who sees what.

When in doubt, the arrangement that is least often wrong is mixed: accounts for known contacts, an open form for everyone else. Keeping both costs little, and it does not force you to guess today how your customers will write to you in a year.

When registration is the right choice

When support is part of a contract and you must be able to show who asked for what. When the client is a large organisation whose people need to see each other’s requests. When the information travelling in your replies cannot end up in the wrong mailbox because somebody mistyped an address.

And when the person writes every week: at that point the account is not an obstacle, it is where they find their own work again. The line between the two cases is not company size — it is how often the same person writes to you.

How OglutTicket handles both

Both models exist side by side, and the part that is usually the problem — the password — exists in neither. Contacts you give access to sign in with their address and a short-lived code, see their company’s requests, and can only open requests on the projects you associated them with. There is no password selection screen anywhere in the product, not even for your own staff.

Anyone without access uses the public form on your own address: name, address, subject and description, then a verification of the address, and from there they follow that request from the private link they received — the same conversation you see, without the team’s internal notes. No user is created.

The limits worth knowing first: the public form has the fields it has, no extra ones are added and there are no different questions per type of request; there is no knowledge base where a customer finds the answer alone; and an email sent to a mailbox does not become a request, because the product does not receive mail.

The complete journey of a request, from the form to the reply, is on how it works. Why there are no passwords at all is explained separately, and it is worth reading before deciding: it changes the terms of the question.