Client Portal: a signed-in space for each customer

The erp.io Client Portal is a customer-facing workspace. Your customers sign in to it, not to app.erp.io, and they see only their own company: orders with a message thread on each, invoices they can view, download and pay, files you have shared with them, subscriptions, and support tickets that are kept separate from order threads. Several people at one customer company can have access, managed from the company profile.

It is run from a staff side where you manage clients and their contacts, services, orders and invoices, with named permissions and an audit log. Pay links are issued from the invoice, and an invoice still in draft can never be paid, so a customer does not land on a dead link.

The portal was built for service businesses whose clients want a single place to see what they have ordered, what they owe and what is happening. That is exactly the shape of a fleet account.

Think about the delivery company with thirty cargo e-bikes, or the university with a bike-share fleet. Their operations manager does not want a text per bike. They want to see which orders are open, download the invoices from last month for their accounts team, pay online, and raise a problem without phoning the shop. The portal does that today: you set up the company, invite their people, and put orders, invoices and files in front of them.

For walk-in riders, the portal is less useful on its own today, because what a rider wants to see is their repair: the quote, the checklist, the photos of the worn cassette, the invoice. Quotes, visits, checklists and invoices already exist in Service, but none of them has a customer-facing view yet. The Service plan has Service exposing quote, visit and invoice views, and booking, to the portal, and that flow is on the roadmap.

So the honest split is: fleet and corporate accounts can use the portal now, with orders and invoices you set up in it. Riders seeing their own repairs, approving quotes and paying for a job will come when the Service views and card payments are built.

The Service plan names the portal as the customer self-service hub. Service already owns the work, the quotes and the invoices. The plan is for it to expose views of them to the portal: a rider signs in and sees the quote for their headset replacement, approves it, and later sees the invoice and pays it. Quote signatures will go through Sign, and payments through Stripe inside Service.

Booking is planned the same way. Service will own requests, bookable services and availability rules, and the portal will be one of the places a customer books from, next to a request form on your website and Phony on the phone.

Until then, the portal and Service run side by side in the same workspace. The checklists you complete in Service produce a PDF you can share with a customer, including as a file in the portal.