Give customers, subcontractors and franchisees a secure login to their own information, instead of a phone call to someone in your office.
Most businesses already hold the information their customers keep asking for. Where is my order. Has that job been signed off. Can you resend the invoice from March. What is my balance right now. The information exists — in the accounting system, the job management tool, a folder in SharePoint — and every request for it costs a staff member ten minutes and an interruption. Customer portal development in Australia is usually bought for exactly that reason. Not to look modern. To stop paying people to read a database out loud.
A portal is a login. Behind it, each customer, client, subcontractor or franchisee sees their own information and nothing else — orders, job progress, documents, invoices, statements, forms they need to submit, approvals they need to give. They get it at nine at night without ringing anyone, and your team stops fielding the same five questions.
We build portals as custom software that connects to the systems you already run, rather than as another system to maintain alongside them. If your jobs sit in SimPRO and your invoices sit in Xero, the portal reads from both and shows the customer one coherent view. That connection work is system integration, and it is what stops a portal becoming a second source of truth someone has to reconcile every week.
A portal is not always the right answer, and we will say so. If you have eleven clients and speak to all of them weekly, a portal is overhead — the relationship is the service. Portals earn their keep when the same low-value question arrives dozens of times a week from people you cannot practically talk to that often. If the people who need the view are internal rather than external, what you actually want is custom dashboards and reporting.
The most requested item, every time. The customer sees where their order or job actually is — scheduled, in progress, awaiting parts, complete — read live from your job or order system, not typed into a status field by someone in the office who has to remember to do it.
Contracts, drawings, test certificates, safety documentation, insurances, statements of work. Customers download the current version themselves. You get a record of who downloaded what and when, which settles the argument about whether a document was sent.
Invoices, credit notes, remittances and a running statement, drawn from Xero or MYOB. Most debtor calls are not disputes — they are people who cannot find the invoice. Give them the invoice and the call does not happen.
Variation approvals, service requests, warranty claims, onboarding forms, purchase order uploads. A submission arrives already attached to the right customer and job, with its reference number and attachments in place, instead of as an email someone has to interpret.
The same pattern pointed inward. Subcontractors submit dockets, timesheets, insurances and SWMS; franchisees see their own sales, orders and compliance status. Head office sees everyone, each site sees only itself. This is common in construction and trades businesses managing a long tail of subbies.
Your staff invite users, set what each one can see, and switch them off — without raising a ticket with us. This sounds minor until the day a client's accounts payable officer leaves and nobody can revoke their access.
We work out who logs in, what they are trying to find, and what they do today instead. There are usually two or three distinct audiences with very different needs. Building for the loudest one is the common and expensive mistake.
We map where each piece of information actually lives and who owns it. This step decides whether the portal is a short build or a long one, and it is worth doing slowly rather than assuming.
We design the screens around the questions being asked. Authentication, roles and record-level access are built and tested first, deliberately, because that is where portals fail — not in the visual design.
We connect the portal to your accounting, job and document systems so it reads live data. Your team keeps working in the systems they already know, and nobody maintains the portal by hand.
Once real customers are using it, usage tells you what to build next and what to remove. A portal is also where customer retention systems usually start, because it is the first place you can see who is engaged and who has gone quiet.
We work on a subscription rather than a fixed project price — monthly billing, a three-month minimum term, and thirty days' notice to cancel. What moves the number is how many audiences the portal serves, how many systems it reads from, and how complicated the permission rules are. Email outreach@drawnai.app with a rough description and we will explain what drives the figure.
Because it is enforced in the data layer, not on the screen. Every request checks the logged-in user against the specific record being requested, so nobody reaches another customer's data by editing a URL or an ID. We test that deliberately before launch, and it is re-tested with every change we ship afterwards.
Your team deactivates that user from the admin screen. Access ends immediately, their history stays intact for audit, and the client's other users are unaffected. We can also build inactivity rules, so an account nobody has touched in months is flagged or suspended automatically rather than depending on someone remembering to tell you.
Most of it lands in the first few weeks, deciding what customers should see and confirming where that data lives. Expect a few hours a week from someone who knows the operation well, not a full-time secondment. Build and integration are on us. The heaviest ongoing task is usually tidying up customer contact records before you invite anyone in.
Some will not, and that is normal. Adoption comes from making the portal the fastest route to something they want — the invoice, the certificate, the status — and from your team answering routine emails with a link instead of an answer. We build usage reporting in, so you can see who logs in and what they look at.
In Australia. Client data we host sits in Australian regions, on Azure in Melbourne and AWS Bedrock in Melbourne. That matters for financial services businesses with data residency obligations, and it removes an awkward question from most procurement processes. The data is yours, and it stays in the country your customers assume it is in.
A first conversation costs nothing and usually ends with a clearer idea of what is worth building — sometimes that answer is “not yet”, and we will say so.
No lock-in templates. Built around you.