Main site

Real Estate AI agent · Showings

Showing & Tour-Scheduling AI Agent

Present the property's published times unchanged from enquirer to enquirer, log the set that went out, and hold confirmation and access for the licensee who holds the written authorisation.

Typical delivery
4–6 weeks
Deployment
Your stack
Licensee signs
Before access
After launch
Agent Care

What this agent does

Offers the slots; never opens the door

In

  1. 01

    Present one published slot inventory per property, read from the showing, rental-tour and calendar systems in scope.

  2. 02

    Offer that set to each enquirer for that property — same times, same earliest slot, same tour modality.

Reason

  1. 03

    Hold any request on a tenant-occupied unit for the licensed property manager, whose entry-notice duty runs first.

  2. 04

    Present the staffed phone path alongside the online one, so a booking does not depend on a single channel.

  3. 05

    Offer nothing the seller's or owner's written authorisation on file does not already cover.

Decide

  1. 06

    Hold access, credential and self-tour questions for the licensee named on that authorisation.

  2. 07

    Escalate accommodation and accessible-tour requests to that licensee instead of answering them.

Out

  1. 08

    Log the offered slot set verbatim, the time it was sent, and each access event against the enquiry.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent presents times and keeps the log; the licensee holding the written authorisation decides who tours and when a credential is issued.

Example workflow

One enquiry, request to authorisation

  1. 1Enquiry receivedPortal enquiry, listing site, brokerage CRM or inbound scheduling request
  2. 2Property status assembledOccupancy flag, written authorisation on file, tour modality and the published slot table
  3. 3Slot set presentedThe published times, the modality, the send record and confidence
  4. 4Controls appliedOccupancy and authorisation checks, parity against the published table, and the confidence threshold

No human action required

Stages 1 to 4 run unaided, and none of them is authorised to confirm a tour or issue a credential — the licensee's lane opens at the authorisation gate.

5DecisionSplits at the confidence threshold
High confidence

Goes to the named licensee to authorise.

Low confidence

Adds a property-manager read first.

Licensee authorisation

The request is held with the offered set, the occupancy flag and the authorisation on file.

Authorise · Decline · Send to property manager

Authorised — tour confirmed

  1. 6Showing systems updatedOnly where write access and authorisation policy allow it
  2. 7Outcome evaluatedSlot-offer parity, escalation outcomes, access events and post-tour incidents

Overrides

What the licensee changes at that gate is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Granting property access or issuing a lockbox or smart-lock credential.
    • Deciding that an enquirer may take a self-guided tour.
    • Adjudicating an identity-verification result from the vendor.
    • Confirming a tour on a tenant-occupied unit.

  • Automation boundary

    Agent acts unaided

    • ✓Present the uniform published slot inventory.
    • ✓Send reminders for a tour already authorised.
    • ✓Escalate occupied-unit and accommodation requests to the licensee.
    • ✓Log the offered slot set and each access event to the audit store.

    Any write happens inside the boundaries agreed at implementation, never ahead of the licensee's authorisation.

    • Varying the slot inventory offered to an individual enquirer.
    • Approving unaccompanied access in any jurisdiction.
    • Extending, reissuing or overriding a code expiry.
  • Answering substantive questions about the property during booking.

Example output

One enquiry, annotated

Everything the agent offers is attached to the inventory it was taken from.

Scheduling output · single enquiry

Illustrative example
Enquiry
Two-bed rental
Offered slot set
The published set, sent whole and in the published order
Earliest slot
Sat 10:00
Authorisation
Written authorisation on file
Confidence
93%
Tour modality
Accompanied — licensee present

As received

Taken from the published inventory and the authorisation record — nothing on this side is chosen by the agent.

Record checks used

  • Occupancy flag
  • Written authorisation
  • Published slot table

Why this slot set

It is the published set, unchanged for this enquirer — the parity the licensee owns.

What the score decides

Below the threshold the request picks up a manager read before it reaches the licensee.

Action

AuthoriseDeclineSend to property manager

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every enquiry

From the enquiry channel

03Scheduling

Offer the published set

Draw on the published slot table, the occupancy flag and the authorisation on file.

01Approved path

Offer the same slots to everyone

Routine requests on authorised properties come back with times attached.

02Human review

Send the licensee the risky ones

Occupied units, accommodation requests and failed verification are escalated, so the licensee's attention lands there.

04

Build an evidence trail

Log the offered slot set, the modality and every access event, on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Showing scheduling

    • ShowingTime+
    • Aligned Showings

  • Rental self-tour

    • Rently
    • Tenant Turner

  • Access and key control

    • SmartRent
    • PointCentral
    • SentriLock
    • Supra eKEY

Agent

Showing & tour scheduling

  • Reads availability
  • Presents the slots
  • Holds for authorisation

  • Identity verification

    • Persona
    • Jumio

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the door

Each control wraps the one inside it. What a layer does not catch is named in the failure-mode map below it.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modePull the agent back to the staffed phone path and stop automated offers when signals degrade.Roll back
L5Version monitoringTrack model, prompt and slot-visibility changes; a vendor calendar default shows only on re-test.Track
L4TraceabilityRecord the enquiry, the offered set, the send time, the decision and each access event.Record
L3Licensee authorisationHold requests for the named licensee; it governs who authorises, not what happens once a tour has run.Gate
L2Policy guardrailsTest each offer against the published table and the authorisation on file; a mismatch it can see returns the request.Restrict
L1Confidence thresholdsRoute low-confidence requests to a property-manager read before the licensee sees them.Require review
Model coreSlot set presented — the published times, the modality, the send record and confidence
L1 – L2
Test whether an offer may stand
L3
Puts the authorisation in a licensee's hands
L4 – L5
Re-test the version changes tracking cannot see
L6
Pulls scheduling back when signals degrade

How Nestack evaluates it

Evaluate the whole booking path — not only the times that went out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — what the enquirer is told

  1. E1Final-output evaluationDid matched enquirers receive the same times and the same modality?
  2. E2Step-level evaluationDid the agent read the right property, occupancy flag and authorisation record?
  3. E3Tool evaluationDid it write to the correct calendar, and only where a write was allowed?
  4. E4Confidence calibrationDo low-confidence requests actually attract more licensee overrides?
  5. E5Slice evaluationHow does performance change across specific enquirer cohorts?
  6. E6Business outcomeHow many bookings needed an escalation, or a remediation after a tour ran?

Floor — the outcome the brokerage answers for

Failure modes

Where each failure originates in the agent

Seven failure modes, each sitting at the stage where it starts.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • SW-01

      Stale occupancy flag

      Self-tour slots offered on a tenant-occupied unit.

    Stage gathers

    Occupancy, authorisation, published slots and channel

  2. 02 · Reasoning

    2 modes

    • SW-02

      Latency read as low intent

      The offered window narrows for an enquirer who replied slowly.

    • SW-03

      Partial verification accepted

      A matching phone number stands in for a completed check.

    Stage proposes

    The offered slot set, the modality and confidence

  3. 03 · Tool / write

    2 modes

    • SW-04

      Credential before authority

      A smart-lock code is written before the written authorisation exists.

    • SW-05

      Expiry beyond the cap

      A temporary code is set past the cap MLS policy sets, leaving a live credential.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • SW-06

      No times available

      One enquirer is told nothing is free while a matched enquirer is sent the set.

    Stage returns

    The times the enquirer sees and the log kept

  5. 05 · Change / Version

    1 mode

    • SW-07

      Slot visibility changed

      A calendar upgrade alters default visibility by enquirer segment.

    Stage tracks

    Model, prompt, slot rules and calendar integration

  • Sev-1 · access granted outside the boundary
  • Sev-2 · matched enquirers see different sets
  • Sev-3 · occupancy degrades, request goes to review
See the complete Real Estate failure-mode catalogue

Affected slices

Overall parity hides the cohorts over threshold

Two cohorts sit above the review threshold while the aggregate still reads acceptable, which is why Nestack reports the slot-offer parity-failure rate by slice and by cohort, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Voucher-holder enquiries3.9%3.5×Review
Accessible-tour requests3.0%2.7×Review
Benign verification failures2.0%1.8×Watch
Enquirers with an assigned agent1.0%0.9×Normal

Bar: slot-offer parity-failure-rate lift vs. the all-enquiry baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

No cycle closes without a new test

A failure leaves behind a paired-slot regression case the next release has to pass. That suite is what the following detection is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Slot-offer parity drops in an enquirer cohort.

  2. 02

    Diagnose

    When the gap widens past the configured threshold, the paired outbound logs are read side by side until the cause is one.

  3. 03

    Improve

    A version stamp and the paired logs travel with the correction.

  4. 04

    Verify

    The paired-slot cases are re-run before anything ships.

  5. 05

    Learn

    Both the regression suite and the scheduling policy carry it from then on.

  6. Learn → Detect

    The return edge. The next detection runs against a suite one case larger.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, scheduling workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Showing workflow discovery and boundary definition.Week 1
  2. 02Showing, tour and access-system assessment.Week 1, Week 2
  3. 03Authorisation, occupancy and entry-notice rule mapping.Week 1, Week 2
  4. 04Slot-inventory ingestion and normalisation.Week 2
  5. 05Uniform-offer logic and parity checks.Week 2, Week 3
  6. 06Confidence scoring and escalation routing.Week 3
  7. 07Licensee authorisation workflow.Week 3, Week 4
  8. 08Showing and access-system integration.Week 5
  9. 09Paired-slot regression cases.Week 4, Week 5
  10. 10Credential and authorisation guardrails.Week 4
  11. 11Observability and trace instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne market, one officeProductionProduction showing systemsAdvancedMulti-market inventory
Introduced at Pilot
Uniform slot presentation✓✓✓
Licensee authorisation✓✓✓
Parity baseline✓✓✓
Introduced at Production
Paired-slot reporting—✓✓
Escalation workflow in your systems—✓✓
Approved calendar write-back—✓✓
Access-event logging—✓✓
Introduced at Advanced
Multi-state and MLS rules——✓
Multi-stage brokerage approvals——✓
High enquiry volume——✓
Enterprise user and role controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your published slot inventory and calendar rules

    Slot-inventory ingestion and channel mapping

    Week 1

  2. 02Representative enquiry threads

    Offer baseline, parity checks and cohort definitions

    Week 2

  3. 03Your lockbox authorisations and access policy

    Access-policy mapping and automation-boundary definition

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Showing, tour and access-system assessment, then integration setup

    Week 2

  5. 05Bookings you had to undo

    Paired-slot regression cases and failure-mode testing

    Week 4

  6. 06What must reach a person before a slot is confirmed

    Confidence scoring, escalation routing, guardrails and approval controls

    Week 3

  7. 07Named licensees and property managers to authorise

    Authorisation workflow, then pilot properties and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases sit on the weeks they occupy. Week 5 carries two bars because evaluation and pilot overlap.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Showing workflow discovery, access-policy mapping and the automation boundary

W2Source integration and the uniform-offer baseline

W3How a slot is offered, when it escalates, and who authorises

W4Paired-slot testing, credential-expiry checks and the evaluation suite

W5Access systems connected, pilot properties and the corrections they surface

W6A week of live bookings under authorisation, then Agent Care takes over

Reading the band
Week 5 shows two bars because two phases actually run in it, not to fill the row.
At the end of W6
Once validation closes, Agent Care owns the running agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Real Estate AI agent

Build a showing agent around your access-authorisation chain.

Show us your slot inventory, your written authorisations and who holds them. A tour that happened cannot be un-happened, so we map the scheduling workflow, set the automation boundary and name what stays with the licensee.

Typical delivery
4–6 weeks
Deployment
Your showing and access stack
Licensee signs
Before access
After launch
Agent Care available

Nestack Agents · Showing & tour scheduling

AGT-RE-07 · Agent Care available after launch

Build a showing agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your showings

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.