Customer portal requirements: a brief to hand a developer

List the last twenty calls your front desk took. The same few questions will repeat. They sound like where is my lab report, what do I owe on the invoice, is the scooter ready, or can you resend last term’s fee receipt.

A question asked daily belongs in the portal. A question asked once a quarter does not. Write the survivors in the customer’s own words and keep the first version small enough to launch within one season, before anyone discusses colours or logos.

The developer turns each question into a screen later. Your job now is keeping the list honest. Be strict. The receptionist, the service advisor or the accounts clerk who answers each question today can confirm how often it really comes.

Write one line per item, giving the document type, how far back it goes and whether the customer may download it or only view it. A pathology report might stay available for a year, while a scanned prescription or an X-ray film never leaves the clinic’s system.

Then name the record that ties everything together, such as a patient number, a job card number, a registration number or a student roll number. One key. No duplicates. Shared accounts need a rule. If two people share a household or a company login, say which of them sees which records and which of them may ask for corrections.

Hide internal notes, discount margins and staff remarks. Mark those fields in the brief. Staff will thank you later.

A portal that anyone can sign up for is a data leak waiting to happen, whether it holds fee ledgers or service histories. Choose one rule. It is short. Either staff create each account at the counter, or a customer registers and staff approve it after matching a phone number against a record.

Decide how login works. A one-time code sent to the registered mobile suits most small firms, since customers forget passwords and reuse them across sites. Say what happens when a number changes. Say what happens when a phone is lost.

Write who can switch an account off, and how fast, whether through the admin console or a call to the vendor. Former client staff lose access that day.

Staff should see exactly what the customer sees. Include the date each PDF went out, the staff member who released it and whether the customer opened it, so one look ends most arguments about what was sent.

Add a staff view of incoming requests. A customer asking for a corrected invoice should create a ticket carrying a status, a named handler and a due date. The alternative is a lost email.

Say which system is the master. A due amount shown in the portal should be read from your accounts package at the moment of viewing, because a stored second copy drifts from the ledger.

Write a short list headed not in the portal. Staff rosters, supplier rates, spare-part stock, payroll and internal approvals usually belong on it, because the portal only reads from the back office through an interface. It never edits records directly.

Close the brief with three launch checks. Decide how many customers you invite first, perhaps one clinic day or one class batch, how many document types go live and which repeat calls should fall. Review all three after one month.

Hand the brief to two developers. Compare their questions, not their quotes. The firm asking about approvals, record numbers and revoked access is thinking about your risk, while the firm asking only about colours is not.