Business Systems

Secure business portals that join your people and systems up

A portal is not a website with a login. It is an operational surface, built so a person in a specific role can finish a specific job without opening four other systems.

What is business portals?

Business Portals are secure web applications that give staff, contractors or partners one signed in place to see the data and complete the tasks their role requires, drawing from systems that would otherwise need separate logins. They suit Australian organisations whose people currently switch between several tools, spreadsheets and email threads to do one job.

Get a fixed written quote
Typical timeline
12 to 22 weeks
What drives cost
The number of distinct roles, the number of systems being integrated, whether offline use is required.
Best for
Organisations where staff juggle multiple systems and manual handovers
You own
The application, the data and the identity configuration
Built with
Single sign-on, role-based access control, audit trails, API integrations
What connects to whatERP and financeJob schedulingDocument storeHR recordsReporting warehouseSingle sign onStaff portal
Role permissions decide what each person sees, so one portal suits every team.

Your handover

What a business portal is for and what it is not

The portals worth building are the ones organised around tasks rather than around departments. A branch manager opening the portal should see the approvals waiting on them, the jobs running late and the stock they are short of, not a landing page with tiles linking to six other systems. That tile page pattern is very common and it delivers almost nothing, because the effort of switching between systems was never the real problem. The real problem is that the information needed to make a decision lives in three places and has to be assembled by a human every time.

  1. 01Role and permission model documented against real duties
  2. 02Single sign-on integrated with your existing identity provider
  3. 03Task based screens for each role in scope
  4. 04Approval chains with thresholds, delegation and escalation
  5. 05Append only audit trail with reporting
  6. 06Integrations to the source systems in scope
  • Offline-capable field workflows where required
  • Administrator tools for access review
  • Source code, infrastructure and accounts in your name
The portal reads from them, writes back where appropriate and presents the combination

So we start by naming the decisions people make and working backwards to the data those decisions need. That tends to produce a smaller portal than clients first imagine, with fewer screens and far more value in each one. It also produces a clear line about what stays where it is. Your accounting package, your rostering tool and your document store keep doing their jobs. The portal reads from them, writes back where appropriate and presents the combination.

  • Task queues and approvals rather than a directory of links
  • Data pulled live from the systems that own it
  • One identity, so joiners and leavers are handled once
  • Screens scoped to a role, not a universal dashboard nobody reads
  • Write back to source systems where it removes double entry

Photos are compressed on the device so a day of site images does not stall on a single bar of reception.

Single sign-on and role-based access done properly

If your organisation runs Microsoft 365 or Google Workspace, the portal should authenticate against it rather than holding its own passwords. That means multi factor authentication is inherited from a policy you already manage, and when someone leaves, disabling their account in one place removes their portal access immediately. Onboarding a new starter becomes a group membership change rather than a support ticket to five system owners.

Role-based access is the layer above that

Role-based access is the layer above that. We define roles against actual duties, then permissions against roles, then assign people to roles. It sounds pedantic and it is the difference between a permission model you can still reason about in year three and a pile of individual exceptions. Access is also scoped by data, not just by screen. A regional manager sees their region's records, a national role sees all of them, and a contractor sees only the jobs they are assigned to. Where the portal exposes personal information, that scoping is part of how you meet your obligations under the Privacy Act 1988 and the Australian Privacy Principles.

How the engagement runs

How a portal build runs

We build in visible increments against a staging environment you can open at any time, and we put a working slice in front of real users early. Portals succeed or fail on adoption, and adoption is decided by the people who will use it daily rather than by the executive who sponsored it.

  1. 01Task discoveryShadow the roles the portal will serve and record what they currently open to finish a job
  2. 02Identity designSingle sign-on configuration, role definitions and the joiner, mover and leaver process
  3. 03Integration auditWhat each source system can expose, at what refresh rate, and what it will accept back
  4. 04First sliceOne role, one complete task, live to a pilot group within the first third of the project
  5. 05Approvals and auditChains, thresholds, delegation and the logging that supports them
  6. 06Offline and mobileField workflows tested on real devices in poor coverage before wider release
  7. 07RolloutRole by role, with the old process retired on an agreed date rather than left running indefinitely
DiscoverDesignBuildTestHandover
Two decisions on your side that keep the project moving

The integration work is usually the long pole. Reading data from a line of business system that was never designed to be read from can take weeks, and the honest scoping of that happens in technical discovery, not in a proposal. Where an existing system has no usable interface, we may need to build one, which is a separate piece of work covered by API development and quoted as such rather than buried.

Approval chains that survive contact with real life

Almost every portal we build ends up carrying approvals: leave, purchase requests, quotes above a threshold, document sign off, safety sign on. The naive version of this is a two step chain that assumes the approver is at their desk. Real organisations need thresholds, delegation, escalation and an override that is recorded rather than hidden.

A request routes by value, by cost centre or by category

We model chains explicitly. A request routes by value, by cost centre or by category. If the approver is on leave, their delegate receives it automatically and the record shows why. If nothing happens within an agreed period, it escalates rather than sitting in someone's notifications. Emergency overrides exist, because operations sometimes need them, and every use is logged and reportable so the exception does not silently become the norm. The audit trail records the full chain, so months later you can answer who approved the variation without anyone searching their inbox.

Field staff, patchy coverage and offline use

If part of your workforce operates on sites, in vehicles or in regional areas, connectivity is a design constraint rather than an afterthought. A portal that fails when the signal drops teaches field staff to go back to paper within a fortnight, and once they do it is very hard to bring them back.

Conflict rules are agreed up front for the cases where two people update the same record

For those workflows we build offline-capable screens. Forms, checklists, job notes and photos are captured locally on the device and queue for upload, with a visible indicator of what has synced and what has not so nobody is left guessing. Conflict rules are agreed up front for the cases where two people update the same record. Photos are compressed on the device so a day of site images does not stall on a single bar of reception. We test this on real handsets in real conditions, because assumptions about coverage made in a Sydney office do not hold on a job site outside Dubbo. Where the field workflow is the whole product, a dedicated mobile app is sometimes the better answer and we will say so.

When you do not need a custom portal

If you already run Microsoft 365 and your requirement is document storage, a news feed and a staff directory, SharePoint does that and you are paying for it. Building a custom portal to replicate it is money spent on a problem your licence already solves. We have talked several organisations out of exactly that project.

The rest of the answer

The custom case appears when the portal must combine data from systems that do not talk to each other, enforce a permission model your existing tools cannot express, or carry an approval process with real thresholds and audit obligations. If your need is outward facing rather than internal, you are probably looking at client portals or supplier portals, which have different security and onboarding requirements. And if the underlying issue is that the same data is rekeyed between two systems every day, the cheaper fix may be workflow automation rather than a new interface over the top. Large organisations with many systems tend to need the portal eventually, which is why we scope this carefully with enterprise clients before committing.

How we scope it

Four ways to scope your Business Portals project

We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.

Business Portals Pilot

One team, one process, proven before you commit further

Fixed written quote, agreed before work starts

  • Role and permission model documented against real duties
  • Single sign-on integrated with your existing identity provider
  • Task based screens for each role in scope
Request a quote
Most common

Rollout

The whole department, integrated with what you already run

Fixed written quote, agreed before work starts

  • Everything in Business Portals Pilot
  • Approval chains with thresholds, delegation and escalation
  • Append only audit trail with reporting
  • Integrations to the source systems in scope
Request a quote

Enterprise

Multi site or multi entity, with the governance that needs

Fixed written quote, agreed before work starts

  • Everything in Rollout
  • Offline-capable field workflows where required
  • Administrator tools for access review
  • Source code, infrastructure and accounts in your name
Request a quote

Support

Changes, training and support as the business shifts

Rolling monthly, quoted in writing

  • Changes and new requirements as the business shifts
  • Training for new staff, recorded so it is reusable
  • Patching, backups and a restore that has been tested
  • Rolling, cancel with 30 days notice
Request a quote

These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.

Questions buyers usually ask

Frequently asked questions

Cost and quoting

What makes one portal cost more than another?

The number of distinct roles, the number of systems being integrated, whether offline use is required, and the depth of the audit and approval requirements. Integration with legacy systems is the most common reason a scope grows. We quantify each of those in discovery and then issue a fixed written quote, so you can also choose to cut a role or an integration from phase one.

Can it work on the tools we already pay for rather than replacing them?

That is our default position. The portal is a layer over your existing systems, not a replacement for them, and we would rather integrate with your accounting package, your rostering tool and your document store than rebuild their functions. Replacement is only worth discussing when a system is genuinely at end of life or blocking work, and that is a separate decision with its own business case.

Ownership and handover

Who owns the portal and the data inside it?

You do. The repository, the cloud infrastructure and the identity configuration are all registered to your organisation, and the data never leaves environments you control. We hold access as collaborators you can revoke. Documentation covers the architecture, the deployment process and the integration contracts, so another development team could take it over without needing us.

What happens after launch?

Portals attract requests, because once people can see their work in one place they immediately think of the next thing. Most clients keep a monthly development block for that. We also monitor errors and usage, which matters here more than on a website: a screen nobody opens after month two is telling you something, and it is usually cheaper to remove it than to keep maintaining it.

Detail and edge cases

How long does a business portal take to build?

Most run 12 to 22 weeks, with a pilot group using a first working slice within the first third of that. Integration is the usual variable. Connecting to a modern system with a documented interface is quick, while extracting data from an older on premise application can add weeks. We assess that during technical discovery so the timeline reflects reality rather than optimism.

Can contractors and external partners use it safely?

Yes, and we design for it. External users sit in separate roles with tightly scoped data access, can be time limited so access expires with the engagement, and are subject to their own multi factor requirements. Their activity is logged the same way staff activity is. We also recommend a periodic access review, and we build the report that makes it a ten minute job rather than an afternoon.

Scope a portal around one real job first

Tell us which role wastes the most time switching between systems. We will come back to you inside a business day with an honest read and a written quote.