An AI leasing pilot needs a narrower question than whether AI works. Choose one workflow and one operational problem: enquiries waiting overnight, tour requests that require repeated messages, or callbacks that lose context. Then agree what evidence would justify continuing, changing or stopping the pilot.
The scorecard below is a measurement framework, not a Tykuno performance claim. Set targets from your own baseline and operating needs. A small pilot can show whether a workflow is reliable even when it cannot yet establish an effect on occupancy or revenue.
Define the pilot before collecting results
Record the properties, channels, hours and enquiry types included. Name the source of each metric and who will review it. Distinguish new prospects from existing residents and exclude spam or test conversations using a rule agreed before the pilot begins. Keep those exclusions visible in the final report.
Capture a baseline using the same definitions. Comparing a busy launch week with a quiet week at a stabilized property will tell you little about the assistant. Record changes in advertising, pricing, availability and staffing so the team can interpret the results instead of attributing every change to AI.
Use a scorecard with explicit denominators
- First useful response: time from the inbound enquiry to a reply that addresses it or starts the appropriate next step. Report the median and a slower-tail measure such as the 90th percentile. Keep automated acknowledgements separate.
- Tour booking rate: unique enquiries that result in a confirmed tour divided by the eligible enquiries in the pilot. Define eligibility before measuring. A suggested time is not a confirmed booking.
- Tour attendance: attended tours divided by scheduled tours whose appointment time has passed. Keep cancellations and reschedules visible rather than hiding them.
- Handoff completion: handoffs where the assigned team accepted and completed the next action divided by handoffs due in the period. Sending a notification does not count as completion.
- Team effort: time spent reviewing, correcting and following up on the selected workflow. Include setup and ongoing administration when discussing total effort.
- Quality: reviewed conversations with factual errors, unsupported promises or missed escalation triggers. State the sample size and how conversations were selected.
Separate speed from correctness
A quick reply that invents availability creates more work. Review a sample across channels and hours, plus every reported failure. Check the reply against the approved source at the time of the conversation. Record whether the answer was correct, whether the action completed, and whether the customer was told the true status.
Keep a short issue log with the problem, its cause, the owner and the correction. Useful categories include outdated information, routing errors, failed write-backs, duplicate tasks and unclear instructions. These categories help you decide whether to change the workflow, improve the information source or narrow the pilot.
Make the comparison interpretable
Illustrative example: a report says that nine of fifty eligible enquiries booked tours. The booking rate is 18%, but the number means little without the period, eligibility rule and comparison group. If two bookings were cancelled, report that separately. Do not substitute enquiries, messages and people for one another across the calculation.
A parallel comparison group can be useful if it is operationally practical and receives comparable enquiries. Otherwise, use a clearly labelled before-and-after comparison and explain its limitations. With a small sample, show the counts alongside percentages and avoid declaring that a short-term movement proves a lasting improvement.
Decide what happens at the review
Set a review date and minimum evidence requirement before launch. Continue when the workflow meets agreed reliability and quality criteria. Adjust it when a specific fix is testable. Pause expansion when the team cannot trust the actions or ownership. A pilot that identifies a broken process before wider rollout has still produced useful information.
Tykuno implementations should be scoped around the customer's systems, operational boundaries and team responsibilities. Use a walkthrough to define the workflow you want to measure, then agree which events can be observed in those systems. Ask for the definitions behind any customer outcome before comparing it with your own scorecard.