Customer Portals in New Zealand

Count the phone calls first

Before anyone quotes anything, spend a week counting. How many times does someone in your business answer where is my order, can you resend that invoice, what is my price on this, has that job been booked?

Most businesses that end up building a portal are surprised by the number. Two or three hours a day of someone's time, spent retrieving information that already exists, for customers who would genuinely rather look it up themselves at 7am than wait until you open.

That number is your business case. It is more reliable than any projection about new revenue, and it is the one to put in front of whoever approves the spend.

Your customers already expect this

They log into their bank, their power company, their courier and their accounting software. When they cannot log into you, the comparison is not flattering — and it is quietly doing damage with exactly the customers you most want, the organised ones who deal with a lot of suppliers.

The competitive argument matters more than it sounds. In a market where three suppliers sell much the same thing at much the same price, being the one that is easy to deal with is a real advantage, and it compounds.

Start read-only

The cheapest useful portal shows customers their own records and lets them do nothing at all. Orders, invoices, statements, job status, documents, warranty information — whatever they currently ring about.

This is worth building on its own. It removes most of the calls, it carries almost no risk, and it teaches you what customers actually open. Almost every business that starts here is surprised by which screen gets used most, and that surprise is worth having before you pay for the transactional version.

Then let them do things

Once customers can act — reorder, request a quote, book a service, approve a job, upload a document — the portal stops saving time and starts making money. Reordering in particular tends to increase order frequency, because the friction that was making people batch things up is gone.

This is where the cost rises, and rightly so. Reading data is safe. Writing it into your systems means handling failures, duplicates, and the case where a customer submits something your process cannot accommodate.

Trade portals are their own thing

If you sell to businesses on account, the portal has to understand things a retail one never does: customer-specific pricing, credit terms and limits, purchase order numbers, several users on one account with different permissions, and someone at the customer's end who approves what the others order.

That complexity is why trade portals cost more, and also why they are worth more. A trade customer who can see their own pricing and reorder without ringing is meaningfully harder for a competitor to take off you.

The integration is the project

Buyers tend to think about screens. Developers think about where the data comes from, because that is where the work is.

• A modern system with a proper API — Xero, most cloud ERPs, most job management software — is straightforward.
• An older on-premise system may have no API at all. That means a database-level integration or a scheduled export, which works, but needs care and adds cost.
• Several systems at once is the common case, and the interesting question becomes what the portal does when one of them is unavailable. A good answer exists. "That won't happen" is not it.

Ask every developer quoting how they plan to connect to what you already run, and what the portal does when that connection fails. The answers will vary more than the prices.

Live or synced?

Live data is better and costs more. Synced every fifteen minutes is perfectly fine for invoices and statements — nobody minds a quarter-hour-old invoice. It is not fine for stock levels if customers are ordering against them, because you will sell things you do not have.

Decide this screen by screen rather than for the whole portal. It is one of the few decisions that meaningfully changes the price and is entirely within your control.

What to compare in the quotes

• Integration approach. Specific answers about your specific systems, not "we integrate with anything".
• Login management. Someone has to invite customers, reset passwords and remove people who leave. Who, and using what?
• Permissions. How does the system guarantee one customer cannot see another's data? This should be enforced in the database, not hidden in the interface.
• Phase one. A developer proposing a read-only first release is showing judgement, not a lack of ambition.

Describe your business, not the software

You do not need to know what to build. Describe what your customers ring about and which systems hold the answers, and up to five developers who have built portals against those systems will tell you how they would approach it. Comparing their integration plans is where the real information is.