Custom software

Customer portal or process automation: what should you build first?

Start with the task and the source of truth. Not every internal process needs a portal and not every portal needs a new backend.

01

A portal and automation solve different problems

Process automation executes recurring checks, handovers and state changes. A customer portal gives an external user secure access to information and actions. Both may use the same data, but their primary purpose differs.

A dashboard on top of an unclear process exposes confusion without solving it. Conversely, effective internal automation may reduce status emails but cannot enable independent collaboration when customers need to upload documents or confirm decisions.

02

Follow one real task from start to finish

Choose a frequent task such as reviewing an enquiry, changing capacity, approving a document or returning an outcome. Record who starts it, which information is required, which decision follows and where the final state is stored.

This route reveals whether an integration is missing, an internal decision process should be automated or an external user needs to perform a step. Start with the smallest component that measurably improves the complete task.

  • Who owns each step?

  • Which system stores the truth?

  • Which exception needs human judgement?

  • Which action demonstrably saves time or errors?

03

Automate the normal route and design the exception

A useful automation has a verifiable trigger, explicit rules and idempotent actions. The same event must not accidentally create two customers, invoices or notifications. Every error receives a recognisable state and a recovery path.

Not everything must be automatic. Incomplete information, conflicting states or risky approval can deliberately enter a work queue for a person. This is stronger than a scenario that silently fails or continues on assumptions.

04

A portal starts with identity and permissions

Once customers or partners sign in, the account's organisation and role must determine which information they may see or change. These boundaries belong in the data model and every server action, not only in hidden menu items.

Let users complete a meaningful task in the portal. Viewing a status, giving feedback, managing capacity, uploading documents or confirming a decision are concrete reasons to return. A general dashboard duplicating emailed figures rarely creates lasting adoption.

05

Choose the first release based on evidence

A strong first release serves one role and one complete route. Measure lead time, errors, status questions and completion before and after release. This shows whether expansion adds value or only creates more screens.

Agree ownership of code, data, hosting and external accounts upfront. Document recovery, permission management and changes too. Custom software remains a product that must be operated safely after delivery.

FAQ

Frequently asked questions

01Can a customer portal be built on top of an existing CRM?

Yes. The CRM can remain the system of record while the portal securely exposes only relevant data and actions.

02Should every process be automated first?

No. Start with one frequent route with clear input, outcome and ownership. Expand only after that route demonstrably works.

03When is standard software more sensible?

When the process is largely standard and configuration fits without major workarounds. Custom software is most useful when the operating model is commercially distinctive or structurally complex.

From growth question to working system

See how we translate this knowledge into a focused sprint, funnel or software project.