How to Document Tenant Repair Requests

Capture the first report without rewriting it

Record the property, unit, reporter, exact date and time received, and communication channel. Include the timezone where it matters. Give the issue a specific title such as “Unit 2B kitchen sink leak.” Preserve the tenant's description as received; place your shorter summary beside it rather than replacing it.

If the tenant says the problem started on Sunday but reports it on Tuesday, keep both dates with their sources. “Tenant reports leak began Sunday evening” is different from an observation made by the landlord. For a phone call, write a contemporaneous note identifying who spoke, what was described, and what remains uncertain. Do not invent a quotation you cannot reproduce accurately.

Save original supporting photos and documents with the request. Note which files arrived with the first message and which came later. A screenshot can help show the conversation, but keep the original message or email where possible. Avoid silently replacing an unclear photo with a later one that shows a different condition.

• Property and unit; a stable issue identifier and specific title.
• Reporter and date/time received, including timezone.
• Original description, contact channel, and original supporting files.
• Reported onset or frequency, clearly attributed to the reporter.
• Current visible condition, urgency assessment, and next action.
• Access preferences and a suitable way to reach the tenant.

Classify urgency as an operational decision

An urgency field tells the person handling the request what to do next. Record who assessed it, when, and the reason: for example, “Active leak reported; contact tenant and inspect promptly.” Keep the assessment separate from a legal conclusion about habitability or compliance. Revise it if new information changes the situation, preserving the earlier assessment in the chronology.

Documentation should not delay a response to immediate danger. Use the property's established emergency contact process or appropriate emergency services first. A submission link is not emergency dispatch, and a recorded request does not mean someone has already read or acted on it. Repair obligations and deadlines depend on the jurisdiction and circumstances; this guide does not establish them.

Record acknowledgment and access separately

Add a dated acknowledgment: who replied, through which channel, what they said, and the proposed next step. “Received your report; arranging an inspection” is an acknowledgment, not a completed repair. Record any follow-up questions and the tenant's answers, including a change in symptoms or availability.

Access preferences are starting information. “Afternoons preferred” does not describe an agreed appointment or supply blanket permission to enter. Keep the proposed window, tenant confirmation, notice or communication sent, and actual visit as separate facts. Follow applicable entry requirements; they vary by location and situation.

For an unsuccessful access attempt, describe the observable sequence without assigning motives. Write “Called at 2:35 PM; no answer; tenant returned call at 2:42 PM; visit rescheduled for 3 PM” rather than “Tenant refused access” when refusal was never stated. Record a stated denial accurately when it occurs, together with the message and the next arrangement. Do not put door codes or other access secrets into a packet you plan to share.

Connect inspection findings and vendor scheduling

At inspection, note the date/time, who attended, what was observed, any safe checks performed, and what could not be checked. Distinguish “water visible under cabinet” from “drain connection failed”: the first may be your observation; the second may be a vendor finding. Take before photos when safe, with a wide view and detail views that locate the affected area.

Keep vendor scheduling in the same record: company or person, appointment window, confirmation, and tenant notification. When the visit happens, add arrival and departure information where available, the findings, work performed, parts used, and any recommendation for another visit. If someone relays a vendor finding by phone, say who supplied it and request the written work note when practical.

A scheduled appointment, completed visit, and completed repair are different events. If the vendor orders a part, record what is pending and who owns the next step. If the vendor cannot reproduce the reported symptom, preserve that finding alongside the original report rather than treating it as proof that the problem never occurred.

Keep completion, files, and follow-up together

Write a completion note stating the work performed, by whom, and on what date. Attach the vendor's invoice and completion photos to the same request. Label whether a cost is an estimate, invoiced amount, or payment; an invoice by itself does not confirm every aspect of the repair or the tenant's experience afterward.

Before and after photos should show comparable views where practical. Describe what changed and identify the date and photographer when known. Keep original files; label any cropped or annotated copies as derivatives. A file uploaded on Friday may show work done on Wednesday, so record the reported event date separately from the date it was entered into the system.

Follow up with the tenant and preserve the answer. “Vendor tested sink and found no leak” and “Tenant reports no further water after two days of normal use” are useful, distinct entries. If follow-up is outstanding, say so. Use a final status that matches the record: open, awaiting part, monitoring, completed, or another clearly defined label.

Example: a kitchen sink leak from text to closeout

This fictional example uses one local timezone, CDT (UTC−05:00), throughout. The texts, phone notes, work report, photos, and invoice remain separate originals, but each has a place in the chronology. In a live log, record the full date on each entry, along with when the entry was actually logged if it was added later.

The access delay remains visible without being exaggerated. The vendor's visit does not immediately close the issue because the damp cabinet still needs a check. The final note explains what was verified and by whom, rather than reducing ten events to “plumber fixed leak.”

Handle recurring symptoms without losing the earlier record

If the leak returns, record the new report date, exact symptoms, and fresh files. Link to the earlier repair so the next person can find what was tried. Use a follow-up on the existing issue when it remains the same ongoing problem, or create a cross-referenced issue when it is a new occurrence. Keep the previous closeout; a recurrence adds information rather than making earlier observations disappear.

Compare locations and symptoms before assuming the cause is identical. A damp cabinet could reflect a different connection or leftover moisture. For condition concerns that began before occupancy, reference the move-in photos and condition checklist to locate the starting observation, while keeping later repair activity separately dated.

A short request-record checklist

• First report: unit, reporter, received date/time, channel, original words and files.
• Response: operational urgency, acknowledgment, responsible person and next step.
• Access: preferences, proposed and confirmed windows, notices, actual attempts.
• Work: inspection notes, vendor scheduling, findings and work performed.
• Attachments: original before/after photos, invoice, work note and file descriptions.
• Closeout: tenant follow-up, remaining work, final status and recurrence reference.

Where IssueLedger fits

IssueLedger gives each issue a timestamped timeline for tenant reports, landlord entries, access notes, vendor visits, photos, and documents. Tenants can submit through the landlord's link without a separate account, including an access preference. Landlords can add follow-up entries and review submitted files. The invited collaborator role lets a property manager add attributed entries to assigned property records.

The app supports PDF exports and share links for record review. It does not automatically import your text messages, schedule a contractor, or replace the normal repair contact process. Enter relevant communications and keep the original sources. File hashing supports checking uploaded-file integrity; it does not establish when a photograph was taken or whether its caption is accurate. See the sample export and the record problems IssueLedger addresses.