Property maintenance request limits by plan

Property maintenance request limits by plan

SiteOps is a facility maintenance request platform for property managers. It helps small-to-mid property managers collect maintenance requests, organize request details, and track request status through a simple workflow.

Plan context matters because a property manager may need the tenant request form to match the property setup. SiteOps supports property-specific tenant request forms and uses property details when showing the form.

This article does not claim a specific request count or numeric request limit. Exact plan limits should be checked in the approved SiteOps product facts or current SiteOps plan settings before publishing any specific number.

How SiteOps handles property-specific request forms

SiteOps has a property-specific tenant request form. The form can show property display details, branding-related settings, owner plan context, and custom categories before the requester submits a maintenance request.

This helps property managers keep the request form connected to the correct property instead of using one generic form for every property.

What the tenant request form collects

The SiteOps tenant request form requires:

. category

. unit or room number

. description

. name

. email

The form also supports an optional photo file.

These fields help the property manager understand what the issue is, where it is located, who submitted it, and how the requester can receive updates.

How a maintenance request starts

When a maintenance request is submitted, SiteOps stores the request with the status new.

SiteOps maintenance request statuses are:

. new

. in_progress

. done

For customer-facing language, these can be explained as:

. new

. in progress

. done

A new request has been created. An in progress request is being worked on. A done request has been completed or marked finished in the workflow.

Owner and requester emails

After a maintenance request is created, SiteOps sends a new-request email to the owner.

SiteOps also sends a confirmation email to the requester. This helps the requester know that the maintenance request was received.

When a request status changes and a requester email exists, SiteOps sends a status update email.

Public status lookup

SiteOps has a public status page that lets a requester look up a request by confirmation code and unit number.

The status page shows request details and sorted request history. This helps the requester check the request without needing access to the owner dashboard.

Request history

SiteOps keeps request history connected to the maintenance workflow. When a request status changes, the request history can show the status change and any note connected to the update.

This helps property managers review how a request moved through the workflow.

What to avoid when discussing plan limits

Plan and limit claims should be handled carefully. Do not publish a specific request limit, plan price, unlimited claim, or plan comparison unless it appears in the approved SiteOps Product Facts or Claim Policy.

The safe way to describe this article is that SiteOps supports property-specific request forms and owner plan context, while request limits should be confirmed from approved plan facts before making numeric claims.

Why this matters for property managers

Small-to-mid property managers may manage requests across multiple properties. A property-specific form helps keep requests connected to the correct property, unit or room number, category, requester, and status workflow.

SiteOps helps property teams collect request details, send owner and requester emails, support optional photos, track statuses, and show public request history.

Final summary

SiteOps helps property managers collect property-specific maintenance requests with required fields for category, unit or room number, description, name, and email. It supports optional photo files, owner and requester emails, status tracking, public status lookup, and request history.

Exact request limits by plan should only be published after confirming the approved SiteOps plan facts.