Self-service or customer portal?

Usually when the phone rings too often. Customers ask about status, arrange collections, move appointments, ask for invoices or report damage, and every enquiry costs internal minutes even though the customer would rather have handled it themselves. Then someone suggests a customer portal or an app, and suddenly you are discussing a large project before anyone has looked at what the user actually needs to be able to do.

The tool separates three decisions that often get mixed together: which service the user should get, where it should be delivered, and how it should be put in place. A self-service solution is not a technical format.

An embedded self-service module lets the user handle one self-contained task directly on your website: checking a status, booking a time, paying an invoice, reporting damage or arranging a collection. Often without a login, using an order number or a personal link. The module reads and writes data in your systems behind the scenes, so the customer gets an answer straight away and your staff only handle the exceptions. A customer portal or web app is the answer when the user has several recurring needs in the same place: their own cases, history, documents, roles and permissions. A mobile app takes all three at once: frequent use, a recurring relationship and a genuine need for the phone. Otherwise the installation is mostly in the way.

That is why a portal is rarely the right first step: if the user only needs one thing, a login and a new account stand in the way, and the project gets expensive before it delivers value. Start with the job that removes the most enquiries. If the need grows, the module can become the first building block of the portal. Fixed rules in the tool: personalisation and login point to a portal, never to an app; the camera, GPS and messages on their own never justify an app; and a standard process has to be checked against the market before anyone recommends bespoke development. We have built this sort of thing before, for example ordering a collection in a waste scheme, where the action the customer takes is wired straight to the rules and systems behind it.

Rarely. Think in terms of a ladder of access and pick the least troublesome level that still protects the information: open access, an order number with one verifying detail, a time-limited personal link, a personal login, or an organisation login with roles. For a single task, a personal link is surprisingly often enough.

More often than most people think. Payment, buying single products, booking, returns, order overviews, subscriptions and support enquiries all exist as finished functions in webshops, payment providers and support systems, and many of them can be embedded directly on your website. Bespoke development only becomes interesting once your workflow has special rules, several parties involved, or has to reach across systems.

Yes, and that is precisely the point. The module on your website talks to a controlled middle layer that checks the details, governs access and connects to your systems: webshop, finance system, customer system or payment. The administration behind it gathers status, history and workflows, so the exceptions land with the right member of staff.

Considerably less than a portal or an app, because the scope is one self-contained task. The price depends on how unusual your workflow is: a light connection to one system is cheapest, while special rules, several parties and several systems push it up. Real figures belong in a discovery call, where we run the numbers on your task and your volume of enquiries.