Property Management Phone-Agent Integration: An Evidence Checklist

“Connects to your PMS” is not a sufficiently precise requirement for a property-management phone agent. It can mean reading public property information, delivering a message to staff, creating a prospect record, or committing a viewing. Each operation needs different permissions, evidence and recovery behavior.

This checklist is for the operator and implementation owner preparing a scoped assisted leasing-intake pilot with staff review. The first version should not depend on autonomous PMS writes. Sources and repository behavior were reviewed on September 26, 2026. The checks below are proposed acceptance requirements, not a claim that a connector has been built or tested.

1. Name the smallest useful integration

Write one sentence describing the result: for example, collect a leasing callback request for an included property and deliver it to a queue the leasing team reviews. Then name the actual queue, its owner and the acknowledgement that proves delivery.

Keep three boundaries separate:

Do not sell the third level when the first two are all that exist. Manual staff entry into the PMS can be an explicit pilot boundary; it should also remain visible in the operating-cost estimate.

2. Verify access for the operator's actual account

Ask the PMS owner which product, account, plan and integration arrangement apply. Obtain written confirmation of the supported access path and the exact operations allowed. A vendor's public API page does not grant this particular pilot permission to use an account.

Buildium's Open API page describes programmatic data access and API-key creation. AppFolio's Stack marketplace describes its partner ecosystem. These are examples of different vendor access models to investigate; neither establishes a configured QuickVoice connection.

Before implementation, record the vendor documentation, access approval, account owner, test environment, credential owner and support contact. Do not ask an operator to paste API keys, resident data or database exports into an initial website enquiry.

If access cannot be established, keep the pilot at approved-information and staff-review delivery. Do not substitute screen scraping or unapproved shared credentials for the missing permission.

3. Map properties and records explicitly

Define how a spoken property name maps to an internal property identifier. Include aliases only when the operator approves them. Similar building names, units in different properties, and callers referring to an old marketing name should not silently select the wrong record.

Decide which fields are actually needed for the initial enquiry. A useful handoff may need a property identifier, callback contact, caller-stated preference, requested follow-up and unresolved question. It does not require exposing resident balances, screening documents, entry codes or another person's history.

For each field, record the source, allowed purpose, sensitivity, correction rule and destination. If a move-in date is approximate, preserve that uncertainty rather than invent a precise date to satisfy a form.

The FTC's security guidance recommends limiting collection and access to business needs. Apply that principle to credentials, logs and review queues as well as to the spoken questions.

4. Separate read permission from action permission

An availability lookup does not authorize a booking. A visible calendar slot does not prove the leasing team can conduct a viewing at that property. An API key with broad rights should not make every endpoint available to a conversational model.

LiveKit's external-data guide explains how tools and application code can retrieve information or take external actions. QuickVoice's reviewed live MCP bridge filters and rejects tools marked as writes, side effects, or requiring confirmation. A separately implemented and permitted action path, with a checked result, is needed before confirming external changes.

For the initial pilot, keep viewing times as requests awaiting staff review. A later action-enabled phase requires its own authorization design and acceptance decision. Do not relabel a write as a read to bypass the tool restriction.

5. Define success, failure and uncertainty

Agree on evidence for each state before implementing the connection. The following is a proposed contract for review:

• Received: the destination returns an acknowledgement tied to the correct request.
• Rejected: a validation or permission failure is visible to the operator, with an approved caller alternative.
• Uncertain: the request may have reached the destination, but the result cannot be verified.
• Reconciled: staff or an authorized process checks the destination and records the actual outcome.

A timeout belongs in the uncertain state when the destination might already have accepted the request. Do not automatically repeat a create operation until duplicate risk is addressed. Keep a request reference or other approved reconciliation key and establish who checks the destination.

Also distinguish a duplicate technical submission from a caller making a new request or correcting an old one. The integration should not merge different properties merely because they share a callback number.

6. Check knowledge freshness and runtime failure

Define how often changing facts are reviewed, what source is authoritative and what the assistant may say if a lookup fails. An old rent quote, cached unit listing or prior transcript should not substitute for verified current availability.

Test permission expiry, vendor throttling, invalid data, delayed responses and unavailable destinations. The expected behavior for the intake pilot is to remain within approved information and preserve a visible unresolved request, not improvise the missing result.

Caller statements and retrieved text should not grant additional authority. Include a fictional call that asks the assistant to ignore the property policy, expose another record or announce a booking without confirmation. Inspect the resulting tool access and record, not just whether the assistant sounded cautious.

7. Prepare an end-to-end evidence set

Use fictional properties and contacts in a controlled environment. Before considering a live pilot, review:

Mark each scenario as not run, passed, failed or blocked, with its actual date and evidence. A checklist entry, prompt or prepared script is not a completed test. Do not publish recordings or request records containing real caller information as demonstration material.

8. Assign operations and rollback

Name the owners of the phone route, provider credentials, property information, staff-review queue and incident response. Agree on who can pause the pilot, how failed requests are reconciled, and what happens to data at the end of the evaluation.

Test returning the incoming call route to the prior approved process. Define how pending requests remain visible during that change. Do not expand to more properties, languages or write-enabled operations merely because the first fictional call worked.

Use the property-management call-intake resource to organize the operator inputs, then compare them with the leasing-intake guide. Review hosted and self-hosted cost boundaries alongside the scoped assisted pilot, and discuss the access and staff-review requirements before selecting an implementation path.