Count the calls your office takes in a day and sort them. A few are real: a complaint, a new customer, a problem on site. Most are a customer asking for something that is already written down somewhere in your system. When is my next service. What is my balance. Can you send that invoice again. Can I get one more unit on the Hill Street job. Every one of those is a call a portal answers without a person, and the people who make them, construction superintendents and AP clerks, would rather not have called either.
What they should see when they log in
Their sites, with the units on each and the next service date. Their balance, with every open invoice and the paid ones. Their open requests and what happened to them. That is the whole home page. Behind it: a list of upcoming services, invoices they can download and pay, and a place to ask for things. All of it under your logo and your colours, because the customer is dealing with you, not with your software vendor.
Paying, and paying every time
An invoice in the portal should be payable in two clicks, by card or by bank, with both prices showing if you run a cash discount program. A customer with four open invoices should be able to pay all of them at once. And the switch that matters most for your receivables is autopay: a customer who turns it on pays every cycle on the due date without anyone chasing. Record the consent when they switch it on, with the words they agreed to, because a card charged on file is a dispute waiting for the paper trail.
Requests, not messages
A free-text "contact us" box gives the office a message to read. A request gives it something to do. The portal should offer the specific things customers ask for: another unit, an extra service, a pickup, a problem with a unit, supplies, a dumpster swap or extension. Each one carries the site, the date wanted and the details, lands in one queue on the office side, and can be turned into a job with everything prefilled. When the job completes, the request closes on its own. The customer sees the status change without calling to ask.
Let them fix their own details
The billing contact leaves and the invoices keep going to her. The superintendent changes his number. Both are calls today, and both can be a form in the portal: contact details, who gets invoices by email, a new contact for the new site. Apply the change immediately, log who made it on the customer's timeline, and tell the office. Do not build an approval queue; nobody works it, and the customer thinks they saved something that never took. Keep the office-only things office-only: the company name on issued invoices, the service address, rates, and deleting a contact who has a login.
Proof, in the portal
The service report for last Tuesday, with the stamped photo, should be one click from the site. A customer who can see the visit does not call to ask whether it happened. The proof of service post covers what makes the photo worth looking at.
Getting them in
The invitation goes to the billing contact and the site contact, from your own email address, with one sentence about why: see your services and pay online. The link goes on every invoice and every service report after that. For an institutional account, the first thing the AP clerk does is find last month's invoice without emailing you, and that is the day the portal paid for itself. The municipal post is about those customers.
What it does to the office
It does not empty the phones. It changes what is on them. The dispatcher who answered "when is my next service" eleven times on Monday answers it zero times and spends the time on the complaint that needed a person. That is the hire.
