Customers don't want a portal. They want control.

Most homeowner apps are completion deliverables. They go live the day the customer moves in and gather dust until they sell. When something goes wrong with the property, the customer does not open the app. They pick up the phone.

This is not a design problem. It is a structural one. A portal that surfaces static documents is not giving customers control over their property. It is giving them access to a filing cabinet they did not ask for.

Why transparency is not the same as control

Developers build homeowner apps because they understand the information asymmetry at the point of handover. The developer knows almost everything about the property: what was built, how, by whom, and to what standard. The customer knows almost nothing. The logic of a portal is to close that gap.

It does not close it, because information access and agency are not the same thing.

A customer with access to their completion documentation can read the boiler installation certificate. That does not tell them whether the boiler is under warranty, who to call if it fails, whether there is a manufacturer service agreement, or what the escalation path is if the recommended call-out company does not respond. Those are the questions customers have. The portal answers the first one.

Control, in the customer's frame of reference, means something specific: I know what I own, I know what to do when something goes wrong, and I can see that it is being resolved. A portal that delivers a document library addresses none of those needs directly. It provides material. It does not provide resolution.

The distinction matters more now than it did five years ago. The New Homes Quality Code has set expectations about response timescales, communication standards, and defect management processes that are visible to the New Homes Ombudsman. Customers who have been given a portal that does not actually facilitate those processes are not better served than customers who had no portal. In some respects, they are worse served, because the portal creates an expectation of responsiveness that the underlying process does not meet.

What the customer is actually asking

In any defect situation, three questions matter. Is this problem recognised? Will it be resolved? When?

Most homeowner portals answer none of these. They are not defect management tools. They are document access tools, frequently with a contact form attached. A customer who submits a defect report through a portal and receives no visible confirmation of status, no assigned contractor, and no resolution timeline, has not been given transparency. They have been given a submission endpoint.

Under the New Homes Quality Code, registered developers must acknowledge defect reports within five working days and respond substantively within ten. That is a managed process with defined obligations. A portal that does not route defect submissions into a tracked workflow, assign them to a responsible party, and surface their current status to the customer is not a NHQC-compliant aftercare process. It is a form on a webpage.

The consequence is predictable. The customer calls. The customer care team takes the call, creates a record in a separate system, and begins the managed process that should have been triggered when the customer submitted through the portal. The portal has added a step, not removed one. The customer has less confidence than before they logged in, because the gap between the portal's apparent functionality and the actual response confirmed that nobody was watching.

When this pattern repeats across a portfolio, the operational cost is real. Customer care volumes are not reduced by a portal that does not actually manage the process. They are sustained, or increased, by the confusion the portal creates. The investment in the app becomes overhead without return.

The record behind the interface

A portal is only as useful as the information it surfaces. Most homeowner portals surface one of two things: a document collection or a contact form. The quality of what the customer sees depends entirely on what was collected, validated, and organised before the customer logged in.

If the completion documentation was not validated at handover, the portal is a front end for a gap. The customer sees a section marked "warranties" containing documents that may or may not be current versions, issued in names that may or may not match their own. Installation certificates are present, but nobody has confirmed they correspond to the units actually fitted. Manuals are there, but the serial numbers do not match the appliances in the kitchen.

This is not a hypothetical failure mode. It is the default condition when document collection runs through a contractor who assembled a handover pack at practical completion without that pack having been checked against a structured requirement set. Document Assurance applied before the customer logs in determines whether the portal delivers confidence or uncertainty. The interface is the last step of that process, not the first.

What customers actually need from the record is specific. They need to know the make and model of every appliance in their home, the relevant warranty registration details, the service contact, and the interval. They need to know what the structural warranty covers and for how long. They need to know who to call for each type of problem and what the developer's response obligation is. None of this requires the customer to read a full legal record of the development. It requires a well-structured register of the physical asset and the obligations attached to it.

Customers also do not read documents. They have questions. The interface that is useful to a homeowner is not a document library. It is an answer engine. A layer that interprets the record in response to natural language queries, whether about how to operate a mechanical ventilation system, what the defects liability period covers, or when the next service for the heat pump is due, is what a customer will actually use. A static document repository is what a customer will stop logging into after the first month.

What the record determines

The developer who governs the property record from practical completion, not as a project closeout deliverable but as a live, validated asset register, is in a materially different position when a defect arises, when a sale occurs, or when a complaint reaches the New Homes Ombudsman.

When the record is structured at handover, the portal delivers something the customer can act on. Validated documents, not a bundle of PDFs. Warranties issued in the customer's name, with confirmed registration. A complete appliance register with serial numbers, manuals, and service contacts mapped to each room. A defect trail where every item has a status, an assigned contractor, and a resolution timeline the customer can see without calling anyone to ask.

The customer who can see that the boiler installation certificate has been checked against the unit actually fitted, that their structural warranty has been issued and registered, and that the issue they raised last week has been allocated to a contractor with a visit scheduled, does not need to call the customer care team to find out what is happening. They know what is happening.

This is what control looks like. Not a portal. Not a document library. A structured record, connected to an active process, surfaced in a way the customer can navigate without assistance.

The regulatory dimension runs through all of it. An Ombudsman investigation does not assess whether a developer built an app. It assesses whether the developer's customer care process was adequate: whether defects were acknowledged on time, responded to as required, and evidenced. A portal that did not capture the defect submission, did not route it, and did not record the response is not evidence of a competent process. It is evidence of a gap between the interface and the reality. When the investigation is live, that gap is the story.

What this means in practice

Homeowner engagement is not an app design problem. It is a record governance problem. An app that gives customers access to what the developer knows about their home is only useful when the developer has actually captured, validated, and organised what it knows about that home. Building the record correctly from the point of handover, with validated documentation, a structured appliance register, and a live defect workflow connected to what the operations team is doing, is what makes the customer-facing layer a useful product rather than a credibility risk. Guided Home's homeowner and tenant portal is connected to the same validated record the operations team works from, so what the customer sees reflects the actual state of their property, not a static snapshot of what was intended at handover.