On-Site Remote Access

Summary

Remote access requests already exist: the installer requests a session, the homeowner approves it from Selora Connect, and the session opens. The weak point is the approval — it is only possible from a person with the app, and that person is often not home. When the technician is standing inside the home, the approval is the only thing standing between the installer and the installation. On-Site Remote Access closes that gap: a technician who is physically on site can approve the pending request locally, from the hub itself.

The installer’s problem

• The job waits for a phone that may never ring. The request is sitting in the homeowner’s Connect, unapproved. The homeowner is at work, traveling, or simply never checks — and the installer is on site, tools out, doing nothing
• A dispatched day gets eaten by one approval. Showing up for a two-hour window, unable to reach the installation, means rescheduling — a full day lost, and the customer hears about the outage again
• The people who could approve are the ones who can’t. The homeowner has to approve, but the most common moment an installer needs access is exactly the moment the homeowner is not around

What’s included

Local approval from the hub

• Approve the pending request from on site: when a remote access request is pending and a technician is physically in the home, the request can be approved locally — the session opens without the homeowner answering
• A physical confirmation step: approval happens through something the technician must press or enter at the hub, not through a phone they might not have — a button on the hub, a local code on the hub’s web page (for example at selora.local), or a similar mechanism; the exact interaction is deliberately open
• It authorizes, it does not bypass: the approval covers the request that is actually pending — a named installer, a defined scope, an expiry — and it is logged as an on-site approval, not as a homeowner approval

What it is for

• Unblocking dispatched installs: the technician stops the day from failing on a missing approval, and the homeowner’s session never opens for anyone who is not on site
• An audit trail the homeowner can read: Connect shows who approved, where (on site), and when — the homeowner learns the install proceeded because a technician was in the house, not that the request vanished

Why it matters

• It protects the dispatch economy. A remote session that opens at the moment of need is the difference between a day completed and a day lost — at scale, that is the difference between a reliable schedule and a fragile one
• It is a permission model, not a back door. The whole design question — what counts as “physically on site”, and what that entitles — gets answered once, in the product, instead of improvised by installers with the hub in their hands
• It closes the loop the homeowner set up. The homeowner installed Selora for supervised, authorized access; a session that waits forever for their approval is the opposite of that

The complexity

• “Physically on site” has to mean something. A code served at selora.local is reachable from anything on the home network — a neighbor, a compromised device, a guest phone on the wifi. Proximity alone is not authorization, so the mechanism (a button, a one-time pairing, a short code shown on the hub) has to be something only someone at the device can complete
• Not a second approval channel. The homeowner’s approval and the on-site approval are different events with different trust assumptions; mixing them weakens both and makes the audit trail meaningless
• Abuse surface. An on-site approval that opens a remote session is a strong capability; the request-to-approve pairing, scoping, and expiry have to be airtight, and the homeowner has to be able to see and revoke what on-site approvals did

Out of scope (for now)

• Approving without a pending request — on-site approval opens the specific request the installer made, nothing more
• Replacing homeowner approval — when the homeowner is reachable, they approve as today; this feature exists for the moment they are not
• Multi-tenant or shared-homes policy — one homeowner, one home, one pending request