Plan a leasing enquiry. Verify the handoff.

Fictional, unexecuted example. This is an authored script for evaluation, not a transcript, observed QuickVoice call, customer result or promise that these steps work in a deployment. Replace every bracketed instruction before testing. Use synthetic people and properties.

Before the call

Choose one managed portfolio and a small approved listing-information set. Assign an owner and review date to every listing fact. Define showing hours, property-local time zone, the actual staff request destination and an approved unavailable-destination route. Have responsible staff approve the identity, recording and privacy disclosures for the exact deployment.

This workflow takes enquiries and viewing preferences. It does not book viewings, reserve units, screen applicants, negotiate terms, access private tenant records, create maintenance jobs or dispatch help.

1. Identify the assistant and its limits

Hello, I am the AI assistant for [approved property-management business name]. I can help with approved listing information or take a leasing enquiry for the team. I cannot confirm a viewing. [Insert the approved disclosure for this deployment.] Which property are you asking about?

If the caller names a property that is absent or ambiguous, ask a clarifying question. Do not choose a unit based on an uncertain match or infer which person lives there.

2. Answer only from approved facts

The approved listing information says [verified fact].

When availability, rent or another answer is missing or out of date:

I do not have verified current information for that question. The property team needs to confirm it.

Do not turn a quoted listing fact into an offer, reservation, guarantee or eligibility decision. Keep the information-source date visible to the evaluator.

3. Collect a minimal request

Would you like the team to review a viewing request, or would you prefer a callback about the property?

What name and callback number should the team use? What date and time would you prefer, in [property-local time zone]?

Only ask for a time preference when relevant. The proposed record contains the verified property reference, request type, caller-approved name and callback details, any clarified viewing preference, the unanswered question and the exact next step stated to the caller. Treat unknown fields as unknown; do not fill them from guesses.

Do not ask for an application, Social Security number, payment card, medical detail, door code or another tenant's information. A transcript is not proof that these fields were extracted correctly. Check the actual saved record.

4. Read back corrections

Let me check the request: [property reference], [callback details], and [viewing preference or question]. Is anything incorrect?

Apply any correction and check the destination record during testing. Caller ID does not replace the caller's agreed callback number.

5. Close without claiming a booking

Use the following only when the implemented flow can verify receipt before the call ends:

Your request was received for the property team to review. Your viewing is not booked. The team still needs to confirm availability and the next step. [State only the approved follow-up arrangement.]

If receipt happens after the call or cannot be verified during it:

I have noted your request in this conversation, but I cannot confirm that the team has received it yet. Your viewing is not booked. [Give the approved alternative contact route.]

Do not promise a response time without a staffed process supporting it. A queued retry or persisted call transcript is not staff acknowledgement. Test both the call's wording and the later delivery outcome.

6. Use an honest failure route

When request delivery fails or the destination is unavailable:

I cannot confirm that your request reached the team. [Give the approved alternative contact route and its actual availability.] I have not booked a viewing.

The operator must define who reconciles failed or duplicate requests. A retry must not silently create another appointment or be counted as a completed handoff.

7. Stop when the call leaves the scope

For applicant screening, policy exceptions or accommodation requests, use the operator's approved staff-review process. Do not approve, deny, infer suitability or solicit unnecessary personal information.

For maintenance or an urgent concern, stop the leasing flow and use the separately approved instructions. This template deliberately does not supply emergency advice. Never diagnose a hazard, promise dispatch or claim a person answered without confirmation. If no approved and tested route exists, the pilot is not ready for live calls.

Review with the actual implementation

QuickVoice's live MCP handler restricts marked write and side-effect tools. A PMS write or booking needs a separately implemented permitted path; caller agreement alone does not enable it.

The property-management workflow and workflow guide describe the scope. Use the 30-case scorecard and pilot checklist to test it. No test has been executed by publishing this script.

Planning template, not a completed review or customer result. All items below start unchecked. The companion 30-case benchmark is synthetic and unexecuted. Passing a finite test set would not prove universal reliability, compliance or commercial results.

Define the job and owners

• Choose leasing enquiries only. Keep maintenance, screening and outbound campaigns outside this pilot.
• Name the property-information owner, implementation owner, request-review owner and fallback owner.
• Define portfolio, hours, time zone, approved call types and which callers are eligible for evaluation.
• Agree what a complete record means: property reference, request type, callback details, relevant preference, unresolved question and truthful stated next step.
• Define the staff acknowledgement window and escalation process from real coverage; do not copy an invented service-level promise.

Verify the implementation, not a logo

• Confirm phone/provider configuration, approved knowledge sources and their review dates.
• Inspect exactly where call records and any extracted fields are persisted. Compare the record with the caller's words.
• Demonstrate the actual staff receipt and acknowledgement process. A transcript, queued retry and staff acknowledgement are different states.
• If a PMS or calendar operation is proposed, verify access, permissions, field mapping, destination success, timeouts and duplicate handling. Otherwise keep the flow request-only.
• Define honest closing language when receipt can only be checked after the call.
• Verify the unavailable-destination alternative and failure reconciliation owner. Do not advertise a transfer until it has actually been demonstrated.

Approve boundaries and data handling

• Have responsible staff approve the exact identity, recording and privacy disclosures and the handling of caller corrections.
• Exclude eligibility decisions, housing recommendations based on personal traits, negotiation, unit reservations and private tenant lookups.
• Approve a separate route for maintenance and urgent concerns, including the unavailable-destination case. Do not diagnose, authorize repairs or claim dispatch.
• Use synthetic callers, addresses and records first. Do not place real caller names, numbers, addresses, recordings, transcripts, tokens or private-system links in public files or the initial contact form.
• Keep evidence in an access-controlled location with an owner, approved retention and deletion process. Put only non-identifying local references in the private scorecard/log.
• Review what every audio, model, storage and analytics provider receives before any live pilot. A checklist is not certification or legal approval.

Run and record the synthetic evaluation

• Run all 30 specifications against the intended configuration; repeat when relevant configuration changes.
• Leave outcomes blank until execution. After execution, record pass, fail or blocked; blocked is not a pass. Record observed behavior, version, reviewer and private evidence reference.
• Mark any observed unsafe disclosure, eligibility decision, false booking/dispatch or missing urgent fallback as a critical failure, even if its scenario was classified standard.
• Stop expansion for any critical failure or untested critical path. Fix it and rerun affected and neighboring cases.
• Review record accuracy, destination receipt, duplicate behavior and actual staff acknowledgement separately. Do not report synthetic scenarios as customer calls.

Establish an honest baseline and pilot log

• Define baseline and pilot periods with comparable call types, coverage hours and inclusion rules. Record changes in staffing, demand and scope.
• Use one private log row per observed call, with a non-identifying record key. Mark eligibility and exclusions rather than quietly dropping difficult calls.
• Use yes, no or unknown for observation fields. An unknown is not success; leave numeric costs and staff minutes blank when unmeasured, not zero.
• Count complete, receipt-verified and staff-acknowledged records among eligible leasing calls. Report the numerator, denominator, unknowns and missing evidence.
• Track corrections, unresolved handoffs, completed staff follow-up and staff time separately. Do not infer viewings held, leases or revenue from intake.
• Use the existing cost worksheet and instructions, replacing illustrative inputs with observed costs and dated quotes. Include engineering and human follow-up.

Decide whether to continue

• Have operational and technical owners review failures, unknowns, operating effort and remaining risks. Agree acceptance thresholds before examining results.
• Limit any live pilot to the reviewed scope, with a way to stop routing calls and a person responsible for monitoring.
• Obtain separate customer permission before publishing a name, logo, quotation, recording or aggregate result. Keep raw evidence private and publish only approved non-identifying findings.
• Record continue, revise or stop, with the decision owner, date and unresolved conditions. Do not replace missing evidence with a hypothetical success story.

For broader setup checks, reuse the existing implementation checklist. To discuss the dependencies without sharing caller records, discuss a leasing-intake pilot.