A login your customers can complete
Sign in by mobile number and one time code, with a reset path that does not depend on an email address they never open.
Web apps
Your customers should not have to message you for a status update
A place they log in to see where their job stands, what they owe and what they signed, so the same three questions stop arriving in your inbox every week. Client portal development for businesses whose customers check in constantly.
Who this is for
For businesses answering the same three questions for the same customers every week: where is my order, what do I owe, and can I have a copy. With a handful of accounts you already know by name, a portal only puts a login in front of a relationship that does not need one.
What you get
What we deliver
The status list that stops the follow-ups
Every job, order or case in one place, each with a plain status, the date it last changed and what happens next.
Documents they can fetch themselves
Quotes, contracts, statements of account and receipts, downloadable without asking your team to resend anything.
Payment inside the portal
An invoice the customer can settle by e-wallet, card, online banking or bank transfer, with the payment landing against the right account.
The staff side of the same portal
Where your team updates a status, uploads a document or answers a request, without anyone touching a database.
Access you control per account
Several contacts under one company, and the ability to decide which of them sees pricing, documents and billing.
A mobile number is the login your customer actually has
Sign-in is where portals fail here. A work email address is something plenty of Philippine customers do not have, do not check, or share with three other people in the office, while a mobile number is the identity almost everyone keeps and can prove. So these portals sign people in by number and one time code, with a reset path that does not depend on an inbox nobody opens. The second thing to design around is that the relationship already lives in Messenger or Viber. A portal that ignores that becomes a second place nobody visits, so it works alongside the thread instead: a short link sent where the customer already is, opening on the exact job they were asking about. Paying follows the same logic, through the e-wallets, cards and online banking a local gateway already supports, plus a downloadable statement of account for the customers who still settle by deposit or over the counter.
Questions
What people ask before they buy this
Will our customers actually use it?
Only if it saves them a step. The portals that get used replace something the customer already does, like chasing a delivery date or asking for a statement, and they are linked from the message thread where that request would otherwise have been sent. If a customer still prefers to message you, they should be able to, and your team should be able to answer from the same screen.
Can customers pay their invoices through the portal?
Yes, and which methods to switch on depends on who is paying. A consumer reaches for an e-wallet and expects to be finished in a few taps. A finance department will still send a bank transfer and wants a statement of account to reconcile against, plus a reference number their bookkeeper can quote. We turn on the methods your actual customers use rather than every one the gateway offers.
Why not just use a shared drive and a group chat?
A folder has no state and a chat has no memory. A portal knows which documents belong to which account, what the current status is and who may see it, and it keeps all that true when the person handling the account is on leave. It is the difference between finding the answer and remembering where someone put it.
Is our customers' data safe in there?
The portal is designed on the basis that it holds real customer records: access scoped to each account, actions logged, files served through a permission check rather than sitting on a guessable public URL, and a retention period you decide rather than one that happens by default. Your business remains accountable for that data even though we built the system, so we document what it stores and where it goes for whoever handles compliance on your side.
Can it read from the system we already use for jobs or invoicing?
Usually, and that is the whole idea. The portal should show what is already true elsewhere rather than becoming a second place to type it. If your accounting or job system has an API, we read from it and the customer sees the same record your team does. If it does not, we agree an import route, or make the portal the place the record is created in the first place.
Web apps
Related services
Ready when you are
Tell us what you are building and we will tell you honestly how we would approach it.