Will our customers actually use it?

They will if it's faster than phoning, and they won't if it isn't. That's why we start with the questions they ask most rather than building a complete portal and hoping.

Is this an e-commerce site?

Not necessarily. Plenty of B2B self-service has no checkout at all — status, documents, history and reordering against agreed terms. Transactions can come later if they make sense.

How does it handle contract pricing?

By reading it from the system that owns it rather than duplicating it. Duplicated pricing drifts, and drifted pricing is worse than no portal.

Can our sales team use the same thing?

Usually, and it often improves the business case substantially. Outside sales typically need the same information customers do, plus a little more.

AliveCommerce / Capabilities / Give customers self-service

Give customers self-service

The phones ring all day for order status, stock levels, invoice copies and delivery dates. Every one of those answers already exists in a system. It's just that only your staff can reach it — so your customers use your people as a search interface.

Does this sound like you?

Tick what applies. The count changes what we'd recommend, and sometimes the recommendation is to do nothing yet.

What's actually causing it.

Almost never carelessness. Usually the predictable result of a decision that made sense at the time.

The data was never meant to be customer-facing

Your ERP was built for internal users. Exposing it safely means a layer in front, and that layer was never in anyone's budget.

Self-service looked like a big project

And done badly it is. So it gets deferred in favour of hiring, which scales linearly and never gets questioned.

It was scoped as IT rather than revenue

Portals get judged on cost when they're actually a sales and retention asset. Framed as infrastructure, they lose every budget round.

What we do about it.

In this order, because doing them out of order is how these projects fail.

Start with the top three questions

Not a full portal. The three things customers ask most, answered self-serve, will remove most of the call volume for a fraction of the cost and prove the case for the rest.

Build against live data

A portal showing yesterday's information creates more calls than it prevents. Integration with the systems of record is the real work.

Design for the customer, not the org chart

Customers don't know or care which of your systems owns what. The portal should reflect their view of the relationship, not your internal boundaries.

Include the people who sell

Outside sales and field staff usually need the same information customers do. The same build often serves both, which changes the business case considerably.

Typical first phase

6 to 12 weeks

Top questions, live data, one customer group

Business case

Call volume

Measured before and after, not estimated

Most common buyer

VP Sales

More often than IT, in our experience

Which way in.

Same team either way. The difference is whether this has an ending.

A defined project

AliveCommerce

Portals, self-service and companion apps built against your live systems. Fixed Budget, Scope Controlled, and built for the revenue team rather than the IT backlog.

Portals and self-service

Continuous ownership

Champion1

The portal and the systems behind it managed together, so the customer-facing layer never drifts out of step with the back office.

See Champion1

What it looks like in practice.

Industrial supply · 45 staff · ongoing

Customers phoned for order status all day

A self-service portal against live ERP data, plus a companion app for outside sales. Built for the VP of Sales, not the IT department.

62%

fewer status calls

Straight answers.

Related.

These tend to travel together.

Sell to customers online“Contract pricing and stock levels don't survive the handoff.”Connect systems that don't talk“An export, an import, and a spreadsheet in between.”Onboard and train faster“Six weeks before a new hire is any use.”

Tell us what's breaking.

We'll tell you which part of this we'd put on it, roughly what it costs, and whether it's worth doing at all — including when the honest answer is that you don't need us.

Start the Conversation

Knowledge and process

Applications and data

Customer and web

Browse by symptom instead

The structure

Continuous ownership

Before you commit

Start with one problem

Priority sectors

Also

Or by situation

Not sure you fit?

Reading

Most read

Proof

Nobody owns the application layer