Trust & Safety

What this page covers

Seeky Ltd ("Seeky", "we", "us") is building an on-demand platform that connects estate and letting agents and landlords with hand-picked, self-employed people - we call them Seekers - who carry out property viewings, inspections and related visits.

Letting someone into a home is the most sensitive part of that. This page sets out plainly who attends a property, how access is granted and withdrawn, what is recorded during a visit, and what protection exists for the person we send. It describes the platform as it stands today, and we update it as controls change rather than describing an end state.

Who attends a property

Seekers are hand-picked. Every applicant is individually reviewed by our team before they are invited onto the platform. Being reviewed is not the same as being checked, so the checks are set out separately below.

• Identity. Government-ID verification will confirm a Seeker is who they say they are before they can take a job.
• Criminal records. Every Seeker will hold a Basic DBS before they can accept jobs. Basic is the level lawfully available for routine property visits.
• Right to work. Right-to-work confirmation and references complete the baseline.
• Higher-sensitivity work. A Seeker's recorded check level determines which jobs they can be offered at all. Visits flagged as involving vulnerable occupants are matched only to Seekers who meet a higher check requirement.

Checks are recorded against the Seeker's account. Where a check is carried out by our team rather than an automated provider, it stays in a review queue until a person records the outcome, and a check that has not cleared will not be marked as cleared.

Identity is bound to the job

Vetting only matters if the person who was checked is the person who turns up. A Seeker must set up two-factor authentication before they can go online and receive work, so the account that accepts a job is bound to a device rather than a password alone. Account-renting has been a persistent problem on other gig platforms; for home access we treat a shared account as a security incident rather than a shortcut, and we will tighten this to a per-job identity check.

Access to the property

• Released at the door, not before. The access credential is issued at on-site check-in: one-time, time-boxed, valid for that property, that visit, that person. Nobody holds standing access between jobs.
• Every movement recorded. Open, close, collection and return are timestamped, location-stamped and attributed to an identified person. That trail is the record we rely on in any dispute.
• Expiry is the default. When the job window closes the grant revokes itself. Codes die, tokens are invalidated, key-safe codes are queued to rotate. Access has to be actively granted; it never persists by inaction.

What is recorded during a visit

• Geofenced check-in and check-out bracket every visit, confirming arrival at and departure from the property.
• Live location while the visit is in progress. Position is shared from check-in to check-out and not outside a job, and while the visit is in motion the client can see it too, not only Seeky. It relies on the Seeker's device, so it pauses if the device is locked or loses signal.
• Evidence, not surveillance. We capture what shows the work was done - media, timings, structured report fields - under a defined retention schedule. We do not track Seekers between jobs.

Protecting the people we send

Seekers often work alone in an unfamiliar property, so we are direct about what our tooling does and does not do.

• Check-in and check-out double as a lone-worker heartbeat, so a visit has a recorded start and end rather than an assumed one.
• Welfare check-ins appear on the job screen while the Seeker is on site. If one is missed, a high-priority safety incident is raised automatically. Nothing is sent to the Seeker to prompt her, so she has to open the app to see it.
• A hold-to-activate SOS records an alert against the job, with the time, and raises it in the Seeky ops console. It does not share the Seeker's location.

The SOS is not a monitored emergency line. It raises an alert in our ops console, but nobody is watching that console around the clock, it does not contact the emergency services, and it does not share the Seeker's location. Anyone in immediate danger should call 999. We say exactly this in the app itself, at the moment the button is used, and we will update this page when a monitored response is in place.

Your data

• We operate under UK GDPR and the Data Protection Act 2018, with a documented lawful basis for what we process.
• We are registered with the Information Commissioner's Office, registration number ZC183006.
• For property and occupant data the client remains the data controller and Seeky acts as processor on their instructions. Anti-money-laundering and Right-to-Rent duties remain with the client. Seekers capture evidence; they do not make those determinations.
• Records and media are minimised by design and kept to a defined retention schedule.

How we handle personal information is set out in full in our Privacy Notice.

If something goes wrong

Tell us and we will investigate. Email hello@seeky.co.uk with the booking reference and we will come back to you. Every visit carries an audited record of who attended and when, which is usually the fastest route to establishing what happened. If a Seeker does not attend, we replace them or the job is on us.

Changes to this page

We will post updates here with a new "last updated" date. Where a control described here changes - a check becoming automated, a monitored response desk going live - we update this page at the same time rather than afterwards.