Client Portal Acceptance Test (QA)

Client Portal Acceptance Test (QA)

1. 01

   Freeze the build and tag the version the client will test

   Record the platform, plan tier, and publish date so any later regression can be traced to a specific release rather than a vague 'last week'.

2. 02

   Walk every role the client's staff will actually hold

   Log in as admin, editor, and read-only viewer; a portal that works for the agency owner but breaks for a client's field coordinator is not accepted.

3. 03

   Verify each data source refreshes on the schedule the retainer promises

   Confirm sync intervals against the contract, not the platform default. Airtable, Noloco, and Glide all expose different refresh cadences, and clients notice stale rows before they notice design.

4. 04

   Test the three workflows the client named in discovery, end to end

   Run each from a clean record through to the notification or status change. Capture screenshots of the passing run for the acceptance file.

5. 05

   Check accessibility on the screens clients touch most

   Keyboard navigation, contrast, and form labels on the top five screens. Accessibility gaps surface in procurement reviews and are expensive to retrofit after handoff.

6. 06

   Stress the record volume the client expects in twelve months

   Load a sample at projected scale and time the list views. Bubble, UI Bakery, and Knack behave differently past a few thousand rows, and the ceiling should be documented before launch.

7. 07

   Confirm ownership of the account, domain, and data export path

   Document who holds billing, where the database lives, and how a full export is produced. Agencies that skip this step hand clients a portal they cannot leave.

8. 08

   Get written sign-off against the frozen scope, with exceptions listed

   Name anything deferred and its owner. Unlisted gaps become free work during the first month of the retainer.