PROJECT“Which finish did they choose?”
Shouldn’t take six messages.
Morgan chooses natural oak for the kitchen cabinets. Today, that decision might arrive by text while a different finish still appears in the estimate. A customer portal can give the decision one clear home.
Morgan selects
The portal saves the finish against the correct project and shows it awaiting confirmation.
The team checks
The project manager confirms availability and whether the choice changes price or timing.
Work moves forward
Only the approved selection creates the purchasing task. The customer sees the confirmed status.
| Customer action | Team responsibility | Automation |
|---|---|---|
| Choose a finish | Confirm availability and scope | Attach the approved choice to the project’s purchasing task. |
| Request extra lighting | Prepare a change quote | Assign the request and notify the owner; do not approve spending. |
| Check installation timing | Publish an approved schedule update | Display the current approved date, not a tentative internal date. |
| Read a progress update | Review the note and selected photos | Publish the approved update to that customer’s project. |
If the purchasing-system connection fails, the selection stays saved. The team sees a delivery issue rather than asking Morgan to choose again. A customer decision, a team approval, and an order placed are three different states.
Build around the questions customers keep asking
What happens next? Did you get my selection? Has that extra work been approved? A useful project portal answers these recurring questions from information your team actually maintains.
The remodeling example makes the workflow concrete, but the pattern also fits an agency reviewing creative assets or a commercial service company coordinating site approvals. Choose the decisions and updates that matter to your customer; do not copy another industry’s screens.
Check your existing customer portal first
Ask whether your current project or CRM software already lets customers make selections, submit changes, and see approved updates. If it does, configuration and a few integrations may solve the problem.
A custom app makes sense when an important customer task spans several tools or cannot be completed in the existing portal. If your only problem is copying an approved selection from one tool to another, scope that automation first.
A change request is not an approved change order
Morgan’s request for under-cabinet lighting needs an owner, a description, and a visible status. It should not automatically change the project price or tell a crew to start work.
Your team prepares the scope and price through its approved process. The portal can display that proposal and capture the next action; the build must define what constitutes acceptance and which system records it. Keep the original request and later revisions distinguishable.
Publish updates customers can rely on
An internal target installation date is not necessarily a customer commitment. Decide which dates and statuses are approved for display, who publishes them, and how changes are communicated.
For photos, show only the images approved for that project. A crew upload can enter a review queue before it appears to a customer. Avoid a portal full of stale information by assigning ownership for each update.
Start with one project type and one customer journey
A first version could include a project overview, one material-selection screen, a change-request form, and approved progress updates. Define customer and staff access, then connect only the operational system needed for those tasks.
Test two customer accounts on separate projects. Neither should be able to see the other’s selections, files, or messages. Also test a withdrawn selection, a revised change request, a failed integration, and an outdated schedule.
Price the portal and the connected work together
Custom portals are quoted for their users, screens, access rules, stored information, and integrations. The $1,500 simple-workflow starting price is not a complete customer-portal price.
GoodHandoff builds in accounts your business controls and hands over the agreed source code, configuration, and operating documentation. Provider subscriptions, hosting, storage, and usage are separate; ongoing support is optional.
Bring examples of the messages customers repeatedly send and the systems your team checks to answer them. That gives us a practical way to decide whether you need better configuration, a connected workflow, or a small custom app.