Tenant Maintenance Request Checklist: Get the Details Right

Every missing detail creates more work.

A resident reports that the sink is broken. The request enters the queue. A coordinator calls to ask which sink. The resident replies two hours later. A technician arrives and learns that the problem is an active leak inside the cabinet, but the resident did not provide permission to enter. The visit must be rescheduled.

The original request was fast. The workflow was not.

A tenant maintenance request checklist gives every channel the same definition of complete. Whether the resident calls, texts, emails, or uses a form, the team collects the information needed to classify, assign, schedule, and confirm the work.

A maintenance request is an operating input

The request does more than notify the property manager. It becomes the source information for triage, staffing, vendor selection, resident communication, recordkeeping, and closure. Weak input creates uncertainty at every later step.

The checklist should not ask for every detail the company might ever want. It should ask for the details that change the next action. Keep routine intake short. Ask additional questions when the reported condition triggers them.

1. Identify the resident and location

Start with the person and place connected to the work:

• Resident name.
• Property address.
• Building, unit, or room.
• Preferred callback number.
• Preferred approved communication channel.
• Relationship to the unit when the caller is not the named resident.

Do not assume the phone number maps to the correct unit. Residents use different numbers, employees report common-area issues, and owners may call about several properties. Confirm the record before adding the request.

2. Capture the issue in plain language

Ask the resident to describe what is happening, where it is happening, and when it began. Preserve the resident's words in the record, then collect the structured details your team needs.

Useful follow-up questions depend on the issue. A request about water may require the location, source if visible, whether water is active, and whether another area is affected. A request about an appliance may require the appliance, symptoms, error display, power condition, and whether the problem is constant or intermittent.

Avoid diagnosing the repair during intake. The purpose is to give the technician or vendor a useful starting point.

3. Check for urgency indicators

The resident's description should pass through the property manager's approved triage rubric. Ask observable questions about immediate danger, active damage, essential services, building access, security, smoke, gas odor, electrical conditions, or other policy-defined risks.

If the condition meets an emergency rule or remains uncertain, move to the approved escalation path. Do not bury urgent information inside a general description.

Urgency categories, instructions, and response expectations must reflect the company's policy and applicable requirements. Intake should apply those rules, not invent them.

4. Record access conditions

A complete request tells the team whether and how the unit can be entered:

• Permission to enter under the approved process.
• Dates or times when the resident is available.
• Lock, gate, concierge, or key instructions already authorized for use.
• Pets, alarms, mobility needs, or other access conditions relevant to the visit.
• Areas or rooms included in the permission.
• Any requirement for the resident or another person to be present.

Do not place sensitive access details into channels or fields that are not approved for them. The process should define where this information belongs and who may see it.

5. Collect useful evidence

Photos, short videos, error messages, and documents can help the maintenance team understand the request before a visit. Ask for evidence when it changes triage, parts preparation, vendor selection, or scheduling.

Evidence should be attached to the correct record with a clear description. A file sitting in a text thread is not useful if the technician only sees the work order.

Do not make evidence a universal condition for service. A resident may lack the device, ability, connection, or safe opportunity to capture it. The workflow needs another path.

6. Document approved troubleshooting

Some companies provide short, reviewed steps for specific routine conditions. The request should record which instruction was given and what happened. This prevents the next person from repeating the same step and gives the technician more context.

Approved troubleshooting must have a stop condition. If the resident reports danger, cannot perform the step safely, or reaches a condition outside the script, the process escalates. Intake is not a remote repair contest.

7. Confirm the next step

The resident should leave the interaction knowing what the team recorded and what happens next. Confirm the issue, urgency category when appropriate, reference number, expected next communication, and any immediate approved instruction.

Do not promise an arrival time that has not been confirmed. If the request is waiting for manager approval or vendor availability, say so plainly. A clear pending state is better than a false commitment.

8. Put the request into the correct system state

The checklist is not complete until the information reaches the system of record. The request should be attached to the correct resident and unit, assigned the proper category and priority, routed to the appropriate queue, and labeled with any missing requirement.

A free-form note that contains all the facts may still be difficult to route or report. Put structured information in the fields your process depends on and preserve the resident's description as context.

Use conditional questions instead of one long form

A good intake experience feels relevant. Begin with the shared requirements, then ask issue-specific questions based on the resident's answers. A water report follows one branch. A lock problem follows another. A routine appliance request follows a third.

An AI agent can run this conversation across phone, text, email, or web while maintaining one record. It can identify missing required information, ask the next approved question, create the work order, and send confirmation. If the request falls outside the rules, it hands the case to a person with the facts already collected.

Measure completeness at intake

Track how many requests reach the queue with every required field, how many need another resident contact, how often access prevents a visit, how often priority changes after employee review, and how often residents call before the next promised update.

These measures show where the intake design creates downstream cost. They also give an AI agent a specific outcome: a complete request at the correct next step.

Property managers have described AI deployments that appeared to handle the conversation but failed to create the actual work order. That failure is a useful test. A request is not complete because the resident received a reply. Verify the system state.

Use callbacks as design evidence

Review repeat calls and messages each month. Group them by missing detail, unclear confirmation, status gap, access problem, wrong routing, or disputed closure. Then change the checklist, conditional question, system field, or update rule that created the repeat contact. A good checklist improves as the team learns where real requests still break.

Collect it once. Move it forward.

Vida helps property managers turn a request checklist into an outcome-based AI agent. The agent gathers the required details, applies approved rules, updates browser-based software, routes the work, requests approval, and confirms the next step.

Bring us your current intake form, call script, and recent incomplete requests. We will help build the workflow and measure the result. Map Your First Agent.