How do cleaners flag a hazard, damage, or an access problem while they’re on-site?

Slate keeps an on-site issue connected to the visit instead of leaving it as an unstructured message. The exact path depends on the problem: an access failure has a dedicated no-access report with required photo evidence; a broken NFC check-in issue has its own visit-linked report. Broader incidents are handled through the authorized operations workflow, which can create a formal incident from the visit record.

Use the visit as the starting point

The cleaner opens the assigned visit at /visits/:id and uses More actions. For an access problem, Can’t access property opens the no-access flow. The cleaner chooses an allowed reason, attaches at least one photo, and can add a dispatch note before submitting. This is deliberately different from canceling a visit: the system records the access event against the visit and preserves the reason and evidence.

The no-access endpoint checks that the cleaner owns the visit, validates the reason, and requires a photo URL. On submission, Slate stores structured visit-linked evidence, raises an operations alert, notifies the escalated property contact when configured, and can flag the visit for review. The event is recorded as not attributed to the cleaner, so a locked door is not silently treated as cleaner fault.

Route damage and other hazards honestly

For a property problem that is not an access failure, use the visit-linked path the account makes available. A broken NFC tag has a specialized visit-linked report that can include a note and photo. The cleaner should not force a hazard into a no-access reason just to make a form submit.

The current cleaner experience does not evidence a universal, cleaner-facing generic incident composer for every hazard or damage category. Instead, the formal incident workflow is available to authorized operations staff from the admin visit record. The admin can describe what happened, classify the incident, attach photos, choose client-side recipients, and optionally require a response with a due date. Internal incidents can be recorded for admin visibility without a client notification.

This distinction keeps the workflow accurate: the cleaner can capture the immediate visit context and evidence through supported paths, while an authorized operator decides whether a broader client incident should be issued.

Give the right team a usable record

Visit-linked evidence gives operations more than “something was wrong.” It identifies the visit, reason or issue type, submitted note, photos, alert state, and any follow-up or incident record. A coordinator can decide whether to dispatch help, contact the property, document damage, reassign work, or ask the client a specific question. Client notifications and recipient selection remain governed by the incident configuration and the operator’s permissions.

What this means for a multi-location client

Your team gets a consistent first report from the field and a controlled escalation path for issues that need client attention. Access exceptions can be separated from cancellations, while formal incidents can carry photos, recipients, response questions, and response dates when an authorized operator chooses that path.

This workflow does not guarantee that a cleaner can report every category through one identical button, that a photo proves cause or liability, or that every alert produces an immediate dispatch. Required photos, allowed reasons, recipients, notification channels, and permissions are configured limits. Safety emergencies still require the appropriate emergency or site procedure; the app is an operational record, not emergency response.

See the on-site issue workflow

Ask Slate to walk through your cleaner visit actions, no-access evidence requirements, NFC or equipment escalation, admin incident permissions, recipient rules, and the follow-up record your client teams need.

Discuss your on-site issue workflow