MLS 101: what an MLS is and why it matters for brokerages

Think of the MLS like a giant, trusted noticeboard for homes in your market. Brokers and agents post the facts about a property there so other real estate professionals (and approved tools) can find accurate, up-to-date information in one place.

• It’s the single place most agents trust as the official listing record — the “source of truth” for a property’s price, status and details.

• Local boards or associations run the MLS for their area and control who can see or use the data.

• Only authorised users and approved tech partners (websites, CRMs, apps) can access the full feed — MLS data isn’t automatically public to everyone.

Why brokers care (simple): when your listing is correct in the MLS, other agents and tech tools show the right info. That means fewer missed leads, fewer confused callers, and a better experience for buyers and sellers.

Typical fields you’ll find in an MLS record

• Listing ID / MLS number

• Address (street, city, postal code)

• Price and status (active, pending, sold)

• Bedrooms / bathrooms

• Square footage and lot size

• Property type (detached, condo, townhouse)

• Photos and virtual tour links

• Public remarks / short description the agent provides

• Open-house dates & times

• Listing agent / brokerage contact details

• Days on market / list date

• Taxes and neighbourhood data (where available)

(Short note) For a voice-AI receptionist, the MLS is gold: it lets the agent or AI read live facts to callers — price, open-house time, who to contact — so callers get accurate answers immediately instead of waiting for a person to look things up.

Who uses MLS systems? Brokers, agents, boards & tech vendors

MLS systems aren’t just for agents — there are a few different people and organisations that touch the data. Below is a simple breakdown of the key players and what they can do.

Who the players are

• Brokers — own the brokerage account, post listings, and usually control which vendors the brokerage allows to access its MLS feed.

• Agents — create and manage listings under their brokerage; they use MLS to market properties and find comparables.

• MLS boards / associations — run the local MLS, set the rules, approve who gets access, and enforce display and data-use policies.

• Tech vendors (CRMs, websites, schedulers, aggregators) — companies that build tools which consume MLS data to show listings, schedule showings, sync leads, or power an AI receptionist. They must be approved to connect.

• Public / consumers — can see limited information on public portals (e.g., Realtor.ca or brokerage websites), but not the full MLS feed.

Roles & permissions — who can read, list and grant access

• List: Agents and brokers list properties in the MLS through their brokerage account.

• Read (full feed): Only authorised users and approved vendors (with broker or board permission) can read the full MLS data.

• Grant access: MLS boards and the broker are the gatekeepers — the board enforces rules, the broker authorises specific vendors for their brokerage.

Why permissions matter — the library card metaphor
Think of MLS access like a library card. The MLS is the library of listing data. Not everyone gets a card — you need permission. Brokers and boards decide who gets a “card,” what sections of the library they can visit, and what they can borrow. That keeps private or licensed information secure, and makes sure vendors use the data the right way.

Quick checklist for brokers before you grant MLS access

• Confirm the vendor is authorised/approved by your MLS board.

• Ask what data fields the vendor needs (only give what’s required).

• Confirm how they will store, secure and delete listing/PII.

• Get a written licence/contract with usage limits and audit rights.

• Designate a brokerage contact to manage credentials and approvals.

Keeping permissions tight protects your listings, your clients, and your brokerage reputation — and it’s the first step before any voice-AI + MLS integration.

Major MLS standards & platforms to know (RESO, REALTOR.ca DDF, IDX)

Here are the core standards and platforms you should know — explained plainly so you can talk confidently with your tech team.

What RESO is (simple + slightly technical)

RESO (Real Estate Standards Organization) defines the common language and API rules the industry uses so different systems understand listing data the same way. Two key parts are the RESO Data Dictionary (standard field names like ListPrice, BedroomsTotal, ListingStatus) and the RESO Web API (a modern REST/OData interface vendors use to request those fields). Using RESO reduces custom mapping work, speeds up integrations, and means fewer surprises when your voice AI asks for a field like “beds” or “price.”

What REALTOR.ca DDF is (Canada-focused)

The REALTOR.ca DDF (Data Distribution Facility) is CREA’s national feed that aggregates listings from many Canadian boards. For brokerages operating across multiple local boards, DDF gives a single, normalized source of listing data to pull from.

What IDX is (what appears on websites)

IDX (Internet Data Exchange) lets brokerages display MLS listings on their public websites. IDX providers and plugins pull approved MLS data and show it to consumers under MLS display rules. IDX is about public website display — not the full, licensed MLS feed used by approved vendors.

Why standards matter (plain bullets)

• Consistency: Everyone uses the same field names and formats.

• Speed: Less custom engineering per board — integrations are faster and cheaper.

• Reliability: Fewer errors when your voice AI requests listing info in real time.

• Scale: Easier to support multiple markets because fields are standardized.

Common vendor platforms & what they do

• Flexmls / Paragon / Matrix (CoreLogic): Local MLS software used by agents to list and search — often the original source of listing records.

• REALTOR.ca DDF (CREA): Canada’s national aggregator for cross-board access.

• IDX Broker / iHomefinder / Diverse Solutions: IDX providers that display MLS listings on brokerage websites.

• ListHub / other aggregators: Distribute listings to portals and channels for broad syndication.

• ShowingTime / ShowingHero: Showing-scheduler platforms that manage booking and availability.

• kvCORE / BoomTown / Follow Up Boss / LionDesk: CRMs that store leads, manage follow-up and calendars — common targets for booking writes.

• MLS routers / normalizers: Commercial services that consolidate multiple MLS feeds into a single, consistent endpoint (useful for multi-board brokerages).

• Website builders + IDX plugins (WordPress, Squarespace): Where public IDX listings are shown and where many leads originate.

• Integration tools (Zapier / custom middleware / API gateways): Glue that links MLS data to voice AI, CRM, and calendar systems (handles auth, caching, and business rules).

Practical note for brokerages

When you talk to a vendor or developer, tell them:

1. Which MLS platform(s) your brokerage uses (e.g., Flexmls, Matrix, Paragon).

2. Whether you use REALTOR.ca / a DDF feed (Canada).

3. Which CRM and showing scheduler you want the voice agent to write to (e.g., kvCORE, ShowingTime).

That upfront info lets engineers scope authentication, data mapping, and routing correctly and avoids surprises later.

How MLS integration powers a voice AI receptionist (business value)

Connecting your voice AI to the MLS turns every inbound call into an opportunity — fast, accurate, and trackable. Below are the real business benefits and simple, everyday examples of how it works on the phone.

Concrete outcomes

• Faster answers: Callers get accurate price, status and open-house info instantly — no waiting for an agent to look things up.

• Higher conversion: Immediate, helpful responses convert more callers into booked showings and qualified leads.

• Smarter routing: The AI uses listing data and caller intent to route high-value calls to the right agent or team.

• 24/7 coverage (without overtime): Your brokerage answers every call, after-hours and weekends, with MLS-backed facts.

• Lower cost than answering services: You replace expensive after-hours teams with an automated front desk that also books showings and writes to your CRM.

• Cleaner leads & tracking: Caller details, which listing they asked about, and the AI’s notes are written automatically to your CRM for follow-up.

Short real-world examples

Example 1 — “What’s the price?”
Caller: “What’s the price of 123 Main St?”
AI: “Listing 123 Main St — current list price is $699,000 and status is Active. Would you like to schedule a showing?”
Outcome: Caller gets the answer and is prompted to book — immediate conversion.

Example 2 — “Can I see it this weekend?”
Caller: “Is there an open house this weekend?”
AI: (checks MLS open-house field) “Yes — Saturday 2–4pm. I can hold a spot for you or send the details by text.”
Outcome: Shows or contact info sent instantly; agent gets a qualified showing request in CRM.

Example 3 — Routing a hot lead
Caller: “I’m pre-approved and want to see similar 3-bed homes.”
AI: Uses MLS to pull nearby 3-bed listings, qualifies budget/availability, then routes the call to the buyer-agent on duty or creates a high-priority lead for immediate follow-up.
Outcome: Hot lead routed fast — higher chance of closing.

These simple flows turn casual callers into scheduled appointments and trackable opportunities — and they do it every hour of the day because the AI can read MLS data in real time (or near real time) and act on it.

Simple technical architecture: voice AI ⇄ middleware ⇄ MLS ⇄ CRM

One-paragraph description
At a high level the voice AI sits in front of callers, the middleware is the “brains + translator” that talks to MLS systems and your CRM, and the CRM is where leads and bookings are written. When a call arrives the voice platform captures intent and slots (e.g., address or MLS#), asks the middleware for listing data (cached when sensible), uses that data to respond or take action (book a showing, route the call), then writes the outcome back to the CRM and notifies people (SMS/email/webhook). That split keeps live call latency low, protects credentials, and isolates business rules in a single place you can audit and change without touching the voice model.

Flow diagram (in words, step-by-step)

1. Caller → Brokerage phone number (SIP/VoIP) → Voice platform (IVR / ASR / NLU / TTS).

2. Voice platform → sends intent + slots to Middleware (API call).

3. Middleware → Authenticates to MLS (RESO / DDF / vendor API) → requests needed fields (cache first if available).

4. Middleware → Returns normalized listing data to Voice platform.

5. Voice platform → Speaks answer, collects confirmations, and captures booking details.

6. Middleware → Writes lead/appointment to CRM (via CRM API / webhook) and triggers notifications (SMS/email/agent routing).

7. If human handoff needed → middleware triggers call transfer or creates high-priority notification to the agent.

Which component does what (compact responsibilities)

• Voice platform (IVR / ASR / NLU / TTS)

  • Converts speech → text (ASR) and text → speech (TTS).

  • Runs conversational logic and slot-filling (intent detection).

  • Calls middleware for data and actions; handles prompts, confirmations, and handoffs.

• Middleware (your brokered API layer / business rules)

  • Authentication: Holds MLS & CRM credentials securely (OAuth tokens, API keys) and renews tokens.

  • Transforms / Normalization: Maps MLS fields (RESO/DDF/vendor fields) into a consistent JSON schema the voice layer expects.

  • Caching: Short-TTL caches for latency-sensitive fields (price, status); longer cache for photos/descriptions.

  • Business rules: Enforces show-hold rules, agent availability, blackout windows, phone consent capture, and display/licensing rules.

  • Rate limiting & retries: Manages MLS rate limits, implements backoff and circuit breakers to avoid live-call failures.

  • Webhooks / Integrations: Writes leads, appointments, notes to CRM, calendar APIs, showing schedulers, and notifies agents.

  • Security & auditing: Logs requests, masks PII in logs, supports audits and access controls.

• MLS / Data source (RESO Web API, REALTOR.ca DDF, vendor APIs)

  • The canonical listing data source (price, status, photos, open-house).

  • Requires broker/board authorization; may impose quotas and field restrictions.

  • Best practice: treat it as authoritative for live fields; use middleware to hide per-board differences.

• CRM & Calendar systems (kvCORE, BoomTown, ShowingTime, Google Calendar, etc.)

  • Store leads, create tasks, hold bookings, and sync agent availability.

  • Receive webhook writes from middleware and return confirmation/status.

Other operational pieces you’ll want

• Secrets store / credential vault (don’t hard-code API keys).

• Monitoring & alerting (latency, failed calls, failed writes).

• Logging & audit trail (who asked for what MLS data and when).

• Privacy/consent capture (audio consent, SMS opt-in logging).

• Testing & sandboxing (MLS sandboxes or simulated feeds for UAT).

Authentication, licensing & MLS access: the permission checklist

Before engineering starts, get these permissions, credentials and policies in writing. Treat this as your pre-project intake — it protects your listings, keeps the boards happy, and saves weeks of back-and-forth during development.

Quick overview (plain English)
To let a vendor or voice-AI read MLS data you must get broker sign-off and formal approval from the MLS board or data provider. That approval usually includes sandbox access, production credentials (OAuth client or API key), and a data-use / vendor licence agreement that spells out what the vendor can show and store.

Permission checklist (broker-facing — tick these before engineering)
Broker approvals & admin

• ☐ Broker-of-record or authorized officer signs off on vendor access

• ☐ Broker provides a named contact who will approve requests and manage credentials

MLS board / vendor approvals

• ☐ Confirmation the vendor is an approved/authorized MLS vendor for your board

• ☐ Copy of the MLS data-use / vendor licence agreement (DLA) with signatures

• ☐ Any insurance or indemnity requirements spelled out (if requested by your board)

Technical credentials & environments

• ☐ Sandbox access (test API endpoint and test credentials)

• ☐ Production access credentials (OAuth client_id / client_secret or API key) delivered securely

• ☐ Token endpoints, base API URL(s) and metadata endpoints (so engineers can read the data dictionary)

• ☐ List of required scopes or permissions (what the token will allow)

• ☐ IP allow-listing (if the MLS requires vendor IPs be whitelisted) — provide vendor IPs early

• ☐ Redirect / callback URLs for OAuth flows confirmed (exact values the MLS will accept)

Data & field access

• ☐ Clear list of fields you’re allowed to read/write (price, status, photos, public remarks, etc.)

• ☐ Media access rules (photos, virtual tours): who can store/serve images and any expiry rules

• ☐ Any fields that are restricted or broker-only (these must be excluded from live voice responses)

Usage, quotas & performance

• ☐ Rate limits / quotas and how they’re counted (calls/minute, calls/day)

• ☐ Any commercial charges, per-call fees or overage rules for API usage

• ☐ Does the MLS provide bulk sync options or only live queries? (important for caching strategy)

Security, privacy & compliance

• ☐ Rules on storage & retention of MLS data and PII (how long vendor may keep caller data/listing snapshots)

• ☐ Required encryption standards (TLS versions, at-rest encryption)

• ☐ Logging & audit requirements (what must be logged and how often the board may audit)

• ☐ Consent & disclosure wording required when the AI reads listing info to the public or captures caller data

Operational & support

• ☐ Support contact at the MLS (email/phone) and expected SLA for credential issues

• ☐ Test listing IDs or sample feed to use in the sandbox

• ☐ Process for renewing credentials and for revoking access if needed

• ☐ Any required branding / attribution text the MLS wants shown when data is used publicly

CRM & calendar integration (the other half)

• ☐ CRM API keys and webhook access for lead writes (kvCORE, BoomTown, Follow Up Boss, etc.)

• ☐ Calendar or showing-scheduler API credentials (ShowingTime, Google Calendar, etc.) for booking writes

• ☐ Confirm which data fields the CRM requires on lead create (phone, listing id, notes, source tag)

What to ask your MLS board — copyable questions

• “Do you allow vendor access for voice-AI / middleware integrations? If so, how do we request approval?”

• “Do you support RESO Web API / DDF access or will we receive vendor-specific REST credentials?”

• “Can you provide sandbox/test credentials and sample listing IDs for testing?”

• “What fields are restricted from third-party vendors? Any photo/media restrictions?”

• “What are your rate limits and is IP allow-listing required?”

• “Please send your vendor licence agreement and any display/branding rules we must follow.”

Red flags & things that slow projects down

• No sandbox/test environment available

• Verbal approvals only — insist on written agreement

• Broker sign-off only available at in-person board meetings with no expedited path

• Unclear or very tight rate limits with no bulk sync option (will hurt live voice latency)

• Photo/media access blocked or expensive — affects ability to send image links after a call

Short sample email a broker can send to their MLS board

Subject: Request for vendor access — Peak Demand (voice-AI)

Hi [Board contact],

Our brokerage would like to authorize Peak Demand (vendor) to integrate our MLS feed with an AI receptionist. Please advise the required steps and provide: sandbox credentials, production API access (OAuth or API key), the vendor licence agreement, and any display or media rules. Also confirm allowed fields, rate limits, and the support contact for credential setup.

Broker-of-record: [Name]
Brokerage: [Brokerage name]
Vendor contact: [Peak Demand contact + email]

Thanks,
[Broker name & signature]

Real-time MLS data: design considerations for live phone calls

When a caller asks about a property during a live call, real-time MLS data is what gives the AI confidence to answer immediately. This section focuses only on live queries: what to ask for, how to ask it fast, and operational rules to keep phone calls snappy and reliable.

Why real-time matters

Callers expect the latest price, availability and showing times. Real-time queries ensure the AI gives accurate answers that don’t embarrass the brokerage or lose a lead.

Which fields to fetch live (must be queried from MLS at call time)

• List price — callers expect current price.

• Listing status (Active / Pending / Sold) — critical for whether you offer showings.

• Open-house times & showing availability — changes frequently; affects booking.

• Agent assignment / contact on record — needed to route the call or confirm the listing agent.

• Current appointment/hold status — prevents double-booking when a hold system is used.

• Short time-sensitive flags MLS exposes (e.g., price change timestamp, temporary holds).

• Minimal confirmation fields used to verify the listing (e.g., street number or MLS#) so the AI confirms it’s reading the right record.

Live-query best practices (make each call fast)

• Request only the exact fields you need (use RESO $select or equivalent) — fewer bytes = faster responses.

• Query by exact identifier (MLS# or internal listing ID) rather than broad searches.

• Keep the response tiny — avoid asking for long text fields or media in the live path.

• Set a short, strict timeout for MLS queries (recommend: 700–1,200 ms). If the MLS doesn’t respond in that window, follow a light fallback (see next).

• Use connection pooling & keep-alive to avoid repeated TCP handshakes.

• Pre-warm or refresh tokens before peak hours so OAuth flows don’t add latency.

• Parallelize dependent calls only when safe (e.g., fetch price and status simultaneously if separate endpoints).

• Compress responses and accept compact JSON formats if the MLS supports them.

Handling rate limits & reliability during live calls

• Know per-board rate limits and budget calls accordingly (design low-cost queries for live path).

• Implement client-side throttling + token bucket so bursts from many concurrent calls don’t blow quotas.

• Use exponential backoff and short retries for transient failures, but keep retry counts tiny in the live path.

• Circuit breaker: if an MLS is failing, trip the circuit to avoid blocking calls; switch to a graceful fallback quickly.

Minimal fallback guidance (keeps call moving without caching heavy logic)

• If the live MLS query times out or fails within the hard timeout, say something concise and helpful (e.g., “I can’t fetch the live details right now — may I text you the listing link and follow up?”) and optionally escalate the call.

• Avoid reading long cached descriptions as a substitute for live data — instead offer to send the listing details by text/email and route to an agent for confirmation.

Security & correctness rules for live queries

• Use TLS for all live MLS calls.

• Do not expose raw credentials in logs; mask tokens in telemetry.

• Respect MLS field restrictions — do not read/announce fields the licence forbids for live public output.

• Log query latency, success/failure, and listing IDs for audits and troubleshooting (mask PII where required).

Monitoring & SLA targets (operational knobs)

• Target median MLS query latency: under 400–700 ms.

• Hard SLA for live query response: ≤1,200 ms (including any small middleware processing).

• Target success rate: ≥99% for live queries during business hours; track errors by board.

• Alert on: sudden increase in query latency, repeated 5xxs from an MLS, or quota-exhaustion events.

Quick example of a minimal live request pattern

1. AI captures MLS# from caller.

2. Middleware issues a targeted query: fetch ListPrice, ListingStatus, OpenHouseTimes, AgentContact, LastModificationTimestamp.

3. If the query returns within the timeout, AI reads the core facts and asks to book.

4. If it times out, AI offers immediate texting/email follow-up and routes the call.

Conversational design for MLS-backed calls (lookup, showings, routing)

When someone calls, the voice AI should feel like a helpful front desk: fast, polite, and focused on getting the caller to the next step (info, booking, or human handoff). Below is a practical design you can give your UX or dev team: core intents, example prompts, the data (slots) to collect, and robust fallback patterns so calls never stall.

Short overview
The system detects caller intent, collects minimal identifying info (MLS# or address), runs a tiny live MLS lookup, gives one or two facts, and then either books or routes the call. Keep voice responses short, confirm actions, and always offer to send links or images by text/email after the call.

Core intents (what the AI must understand)
• Listing lookup — caller asks for price, status, beds, or basic facts.
• Book showing / schedule appointment — caller wants a viewing now or later.
• Open-house info — times, instructions, special entry details.
• Agent routing / connect to agent — route to listing or buyer agent, or voicemail.
• Qualification / lead capture — capture buyer readiness, budget, timeline, pre-approval.
• Similar listings / compare — caller asks for other nearby or similar properties.
• General info / directions — address confirmation, parking, access notes.
• Escalation / urgent lead handling — hot buyer, quick-closing timeline, immediate agent callback.

Example prompts & short sample dialogues
Listing lookup
Caller: “What’s the price of 123 Main St?”
AI: “I can check that. Do you have the MLS number or should I look up by address?”
Caller: “MLS 555-123.”
AI (after fast lookup): “123 Main St is listed at $699,000 and is Active. Would you like me to hold a showing slot or send the listing link by text?”

Book showing
Caller: “Can I see it this Saturday?”
AI: “I can check availability. What time works best for you — morning or afternoon?”
Caller: “Afternoon.”
AI (checks showing scheduler/agent calendar): “There’s a slot at 2pm. Would you like me to hold it and send a confirmation text?”

Agent routing (hot lead)
Caller: “I’m pre-approved and ready to buy this week.”
AI: “Great — do you want me to connect you to the buyer agent now or schedule a call back within the next 30 minutes?”
Outcome: route to agent with a high-priority tag and all caller/listing context.

Slot collection (what to capture, in order of priority)
• Listing identifier: MLS number (best) OR full street address (house number + street + city).
• Caller name (first + last) and best phone number (confirm digits).
• Caller role: buyer, seller, renter, or agent.
• Preferred showing window: date(s) and time-of-day (morning/afternoon/evening).
• Email or opt-in for SMS (for sending listing link/photos).
• Buyer readiness: budget, pre-approval status, timeline to buy (optional but high-value).
• Permission/consent: capture explicit consent to send SMS/email and to leave voicemails.
• Agent preference / routing rule: request to speak to listing agent, team lead, or on-call agent.

Slot collection UX tips
• Ask the minimal slot that lets you proceed (MLS# or address).
• Confirm back short values (“You’re asking about 123 Main St, correct?”).
• Confirm phone number by reading back last two digits only for verification.
• Capture consent phrased simply: “May I text you the link to this listing?” — record yes/no.

Fallback patterns and graceful degradation
• If caller can’t provide MLS# or the address is ambiguous: “No problem — can you spell the street name or tell me a nearby cross street or city?”
• If MLS lookup times out or fails within the live timeout: “I can’t fetch live details right now — may I text the listing link and have an agent call you back within X minutes?”
• If the caller provides partial info (e.g., “the blue house on Elm”): ask one quick clarifying Q (street number or nearest intersection) and then offer SMS follow-up with matches.
• If voice NLU fails repeatedly: fallback to an offered transfer: “I’m having trouble — would you like me to connect you with an agent?”
• If caller is urgent/hot (pre-approved, ready now): immediately escalate to human routing rules and mark as high-priority lead.

Handoff & routing rules (when to transfer to a human)
• Transfer immediately for safety or legal issues, or when the caller insists on an agent.
• Transfer when the lead score crosses a threshold (budget matches, pre-approval=yes, timeline=immediate).
• Use “warm handoff”: transfer and pass a summary (caller name, listing, intent, key answers) so the agent doesn’t start cold.

Confirmation & UX finishers (always do these)
• Confirm action in plain language: “Okay — I’ve held a showing for you on Saturday at 2pm and sent a confirmation text to 555-123-4567.”
• Provide next steps: who will call next, expected time, and what the confirmation contains.
• Send a post-call SMS or email with the listing link, photos, agent contact, and show instructions.
• Log the call and write lead to CRM with tags: listing_id, intent, lead_score, call_notes.

Design rules & voice UX best practices
• Keep replies short — 1–2 sentences for live facts; avoid long paragraphs.
• Use plain English; avoid MLS jargon unless the caller is an agent.
• Confirm before making bookings or transfers ("Do you want me to book this?").
• Avoid reading long descriptions on the call — offer to text/email instead.
• Capture consent early for SMS and voicemail; record consent in the CRM.
• Provide clear opt-outs ("Reply STOP to opt out of texts").

Example NLU intent samples (utterances you can feed the model)
• Listing lookup: “What’s the price of [MLS#],” “Tell me about [address],” “Is 123 Main still available?”
• Book showing: “I want to see [address],” “Can I book a showing for [date/time]?”
• Open-house: “When is the open house at [address]?”
• Route to agent: “Can I talk to the listing agent?”
• Qualification: “I’m pre-approved,” “My budget is about $X.”

Handling recognition errors & noisy calls
• If numeric slots (MLS#, phone) are misheard, read back and confirm specific digits.
• Provide easy DTMF fallback: “You can also press 1 to confirm this listing number.”
• If repeated misunderstandings occur, offer SMS follow-up: “I’m having trouble hearing — may I text you a short link to confirm?”

Security & compliance in conversation
• Never read or store sensitive PII in logs in plain text; mask where required.
• Offer and record explicit consent for SMS and data storage.
• Respect MLS display rules — don’t read aloud restricted fields; keep required attribution when sending public links.

Quick scripts you can copy into dialogs
• “I can look that up — do you have the MLS number or the full address?”
• “Price is $X and status is Active. Would you like me to hold a showing or text you the listing?”
• “I’m unable to fetch live details right now — can I text you the link and have an agent call you back within 30 minutes?”
• “Are you calling as a buyer or seller? This helps me direct you to the right person.”

Finish with measurable handoffs
Always ensure that after the call there is a single next step recorded: booked showing, agent callback scheduled, or follow-up text sent. That makes it easy to track conversion and shows ROI quickly.

Security, PII handling & MLS compliance for voice interactions

Keep security simple and practical: protect people’s data, follow MLS rules, and make sure your agents and vendors can prove they acted correctly. Below are plain-English best practices and an actionable checklist you can use with vendors or tuck into an onboarding packet.

Core principles (plain)

• Minimize what you store — only keep what you need to run the business or meet legal/MLS requirements.

• Encrypt everything in transit and sensitive data at rest.

• Mask or redact sensitive pieces in logs and reports.

• Follow each MLS board’s display and media rules exactly (attribution, photo handling, restricted fields).

• Capture caller consent for recordings/SMS and log that consent where the CRM can see it.

Retention guidance (what to keep and how long)

• Real-time cache for live MLS snapshots: very short (minutes to hours). Use strict TTLs (e.g., 1–24 hours depending on field).

• Call recordings used for QA or dispute resolution: keep only as long as needed — common practice is 30–90 days unless a legal hold or brokerage policy requires longer.

• CRM lead records (name, phone, listing referenced, call notes): keep according to your business needs and local law — typical range 1–7 years depending on tax/transaction rules and lead-lifecycle needs.

• Audit logs (who accessed what MLS record when): retain long enough for compliance and troubleshooting — often 1–3 years, secured and access-restricted.

• Delete or archive data automatically at end of retention with verifiable processes; document retention periods in a vendor SLA.

Encryption & transport (easy rules to require of vendors)

• Require TLS 1.2 or 1.3 for all API calls (voice → middleware → MLS/CRM).

• Require encryption at rest for all sensitive data (recommend AES-256 or equivalent).

• Use a secrets manager / vault (no hard-coded keys or secrets in code).

• Require short-lived OAuth tokens where possible and automatic rotation for keys/secrets.

Logging policy (what to log — and how)

• Log essentials for ops/troubleshooting: request IDs, latencies, success/failure, MLS listing ID referenced, and anonymized caller identifiers.

• NEVER store full PII in plaintext logs. Mask phone numbers (e.g., show only last 2–4 digits) and redact names/email in logs used for debugging.

• Keep a separate, access-restricted audit log that records credential use and token issuance for compliance reviews.

• Make logs searchable for incidents but enforce RBAC so only authorised staff can view sensitive items.

• Define log retention and automatic purge policy consistent with your retention guidance.

Caller consent & data capture (simple scripts to use)

• On call start, capture quick consent if you will record or text: “I may record this call and send you a text with the listing — is that OK?” — record the yes/no answer in the CRM.

• For SMS opt-in, log the opt-in channel and timestamp and offer an easy opt-out (“Reply STOP to unsubscribe”).

• Store minimal proof of consent (who, when, method) alongside the lead record.

MLS display, media & branding rules (what brokers must enforce)

• Treat MLS rules as contract terms — follow each board’s display attribution, photo usage, and data-sharing rules exactly.

• Do not alter photos or remove copyright/attribution overlays unless the MLS permits it.

• Don’t announce or expose fields the MLS marks as restricted or broker-only — exclude those from voice responses.

• When sending public links or embedding MLS data, include required attribution text or logos per the board’s display policy.

• Keep copies of vendor licences/agreements and any board approvals documenting permitted uses.

Practical vendor requirements (demand these in contracts)

• Data encryption in transit & at rest; secrets management.

• Clear retention schedule and auto-delete/archival processes.

• Masking/redaction in logs and production telemetry.

• SLA for credential rotation, breach notification (e.g., notify within 72 hours), and incident response.

• Ability to produce audit logs on request and support MLS audits.

• Signed vendor licence / DLA with the board and broker-of-record.

Incident & breach playbook (quick steps)

1. Isolate affected systems (revoke compromised credentials).

2. Notify broker-of-record and board contact per contract terms.

3. Assess scope (which records, which time window).

4. Notify impacted people if required by law and your policy (follow local privacy law).

5. Restore from secure backups, rotate keys, and run a root-cause analysis.

6. Document everything and update the SLA/policy to prevent repeats.

Quick checklist brokers can copy into an RFP or vendor form

• Does the vendor use TLS 1.2/1.3 and AES-256 (or equivalent) at rest? Y/N

• Where do you store secrets? (secrets manager / vault required)

• What are your default retention windows for recordings, logs, and leads? (request values)

• How do you mask PII in logs and telemetry? (ask for an example)

• Do you support token rotation and short-lived OAuth tokens? Y/N

• Provide copy of vendor licence agreement and MLS board approvals.

• Provide sample consent script and evidence of SMS opt-in handling.

Testing, staging & demos: how to prove it to a brokerage

Goal: show the brokerage the system is reliable, fast, compliant, and actually generates booked showings and qualified leads. Run a short, measurable pilot and a focused demo so stakeholders can see live MLS lookups, booking flows, CRM writes, and human handoffs — all without risking production data or agent time.

Sandbox ideas
• Use MLS sandbox/test feeds or sample listing IDs the board provides; never use live prod credentials in early testing.
• Ask the board for REALTOR.ca / RESO sandbox access (or per-board test endpoints) and a set of test listing IDs that cover common cases (active, pending, price-changed, open-house).
• Run voice flows on a staging phone number (SIP/VoIP) that rings only test devices; use test SMS shortcodes or sandbox SMS providers to validate links without spamming real customers.
• Create test agent accounts in the CRM and calendar (non-production) so writes and holds don’t interfere with real schedules.
• Simulate high-load bursts with synthetic calls to test rate-limit behaviour and circuit-breakers per board.
• Use a “canary” small real-world pilot (1 office / 1 team) after sandbox success to prove behaviour in production with limited exposure.

UAT script (step-by-step scenarios with pass/fail criteria)

1. Listing lookup — basic success
   • Action: Call staging number, ask “What’s the price of [test MLS#]?”
   • Expect: AI confirms MLS#, reads price and status within SLA, offers to send link.
   • Pass if: Response < SLA (e.g., 1,200 ms live-path), price/status match MLS test feed, SMS link sent and received.

2. Open-house & booking
   • Action: Ask about open-house and request a showing for a specified time.
   • Expect: AI finds open-house, offers available showing windows, holds slot in test calendar, sends confirmation SMS.
   • Pass if: Calendar hold exists in test calendar, CRM lead created with listing_id and slot, SMS confirmation received.

3. Agent routing & hot lead escalation
   • Action: Caller says “I’m pre-approved, ready to buy this week.”
   • Expect: AI flags high-priority, routes/transfers to test agent or schedules immediate callback.
   • Pass if: Routing occurs, agent receives high-priority notification, CRM lead labeled priority=true.

4. Failure/fallback path
   • Action: Simulate MLS timeout or rate-limit during live query.
   • Expect: AI uses graceful fallback phrase, offers SMS follow-up and agent callback, and logs failure for audit.
   • Pass if: Fallback prompt occurs, SMS follow-up queued, error logged with trace ID.

5. Partial/ambiguous info handling
   • Action: Caller gives partial address (“the blue house on Elm”).
   • Expect: AI asks clarifying Qs once or offers to text matches; does not hang.
   • Pass if: Clarification step executed, candidate matches sent by SMS, no repeated NLU failures.

6. CRM & data retention verification
   • Action: After multiple test calls, inspect CRM.
   • Expect: Leads created with correct tags (listing_id, intent, lead_score), consent recorded, PII masked in logs per policy.
   • Pass if: All required fields present, consent timestamp stored, logs masked.

KPIs to demonstrate ROI in a pilot (how to measure success)
• Calls answered rate — % of inbound calls answered by AI (target: 95%+ for after-hours).
• Live lookup success rate — % of live MLS queries that return within SLA (target: ≥99% in pilot).
• Bookings per call — # of showings booked per 100 calls (compare pilot vs baseline).
• Conversion lift — % increase in calls → booked showings (pilot vs pre-pilot).
• Lead quality / lead-to-contact rate — % of AI-captured leads that convert to agent contact within 24–72 hours.
• Time-to-book — median time from first call to booked showing.
• Cost per handled call / cost per booking — compare AI pilot costs vs current after-hours answering service fees.
• CRM write success rate — % of successful lead writes (target: 100% for test accounts).
• Agent satisfaction & NPS — short survey of agents after pilot (ease-of-handoff, lead quality).
• Error & fallback rate — % of calls that hit fallbacks (aim low; use to tune TTLs/timeouts).
• MLS query latency (median & 95th percentile) by board — must meet live-path SLA.

Demo plan & runbook (10–15 minute live demo example)
• Prep (30–60 min before demo): verify sandbox creds, pre-load test listing IDs, confirm test calendar availability, ensure test agent device is online, and prepare a short KPI dashboard.
• 0–2 min: Quick intro — what you’ll show and pilot goals (bookings, costs, call coverage).
• 2–6 min: Live lookup demo — simulate inbound call, show MLS lookup, read price/status, send SMS link.
• 6–9 min: Booking flow — book a showing, show test calendar entry and CRM lead creation.
• 9–11 min: Routing & hot lead — show a pre-approved caller flow and transfer/priority write.
• 11–13 min: Failure demo — trigger an MLS timeout and show graceful fallback and logging.
• 13–15 min: Review KPIs, next steps, and pilot success criteria; invite Q&A.

Pilot scope, timeline & success criteria (example)
• Scope: 4-week pilot, 1 office, 1 team, daytime + after-hours coverage on a staging number that forwards to production on success.
• Volume target: 500 test calls or 2–4 weeks of normal inbound volume (whichever happens first).
• Success criteria (example pass rules): live lookup success ≥98%, bookings per call up 10% vs baseline, CRM write success 100%, agent satisfaction ≥7/10.
• Roll / rollback plan: if any KPI breaches critical thresholds (e.g., lookup success <90% for 24 hours), pause pilot and remediate; use feature flags to disable MLS live-path without affecting core telephony.

Deliverables to hand the brokerage after pilot
• Pilot report with KPI comparisons and a replay of 10 representative calls (sanitized).
• List of incidents and fixes applied.
• ROI model showing cost per booking vs answering service.
• Recommendation: go/no-go and suggested rollout schedule.

Practical checklist before you start testing or demoing
• Get sandbox + prod credentials and test listing IDs.
• Create test CRM & calendar accounts and test phone numbers.
• Prepare an SMS sandbox and consent flow.
• Pre-seed a few test listings that surface typical edge cases (price change, restricted field, open-house).
• Prepare a KPI dashboard and sample call recordings (sanitized) for review.

Voice AI Integration checklist for brokerages (pre-sales & onboarding)

• ☐ Identify which MLS(s) your brokerage uses (platform names + board contacts)

• ☐ Confirm whether you use REALTOR.ca / DDF (Canada) or any aggregator feeds

• ☐ Get broker-of-record sign-off to authorize vendor access and vendor contact details

• ☐ Request sandbox/test API access and sample listing IDs from each MLS board

• ☐ Request production API credentials (OAuth client_id/client_secret or API key) and token endpoints

• ☐ Confirm required API scopes, rate limits, and IP allow-listing rules per board

• ☐ Provide vendor with CRM API endpoints, webhook URLs, and test CRM accounts (kvCORE, BoomTown, etc.)

• ☐ Provide calendar/showing-scheduler API credentials (ShowingTime, Google Calendar) for booking writes

• ☐ Agree on the minimal field set the voice agent needs (price, status, open-house, agent contact, listing id)

• ☐ Identify any MLS-restricted fields or media rules that must be excluded from live voice output

• ☐ Define caching policy expectations and TTLs for live fields (price/status) with the vendor

• ☐ Confirm retention, logging, and PII handling rules (how long leads/recordings are stored)

• ☐ Provide vendor with test phone numbers and SMS sandbox info for UAT/demo flows

• ☐ Assign a single brokerage technical contact responsible for credential approvals and troubleshooting

• ☐ Agree on SLAs for credential issues, support contact at the MLS, and escalation path

• ☐ Set pilot scope, duration, KPIs (lookup success rate, bookings per call, CRM write success) and pass/fail rules

• ☐ Review and sign the vendor licence / data-use agreement and any insurance/indemnity requirements

• ☐ Schedule training for agents on handoff procedures and how to handle AI-enabled leads

• ☐ Prepare go-live checklist: production creds swapped in, monitoring enabled, rollback plan, and agent support on standby

Developer appendix for brokerage owners: MLS integration (non-technical)

A plain-English appendix you can read in 2–3 minutes. It explains what Peak Demand will do, what your team needs to approve or provide, how you’ll see results, and the simple next steps to get started — without code or tech-speak.

What Peak Demand delivers (clear, non-technical)

• Project intake & plan — we map your goals (better call handling, more showings) to a simple integration plan.

• Permissions + approvals help — we prepare the exact broker and MLS requests you need, and we handle most of the back-and-forth with boards.

• MLS connection & data handling — we connect your phone/AI to the correct MLS feed(s) so calls return accurate listing facts (price, status, open houses).

• CRM & calendar linking — we wire the AI to your CRM and showing scheduler so booked showings and leads appear where your agents work.

• Conversation design & scripts — we write the call scripts the AI uses (how it asks for an MLS#, how it offers a showing, how it routes hot leads).

• Pilot/demo & proof — we run live tests and a small pilot so you can see bookings and CRM writes with real calls (no risk to production schedules).

• Training & playbook for agents — short training and a handoff guide so agents know how AI-leads are handled and how to follow up.

• Ongoing support & monitoring — we monitor lookups, failures, and lead flow and provide a clear support path.

What we’ll need from your brokerage (simple checklist you can act on)

• Broker-of-record sign-off to authorize the vendor and a named technical contact.

• Which MLS board(s) and platform(s) you use (e.g., Matrix, Paragon, Flexmls) and the board contact if available.

• Confirmation whether you use REALTOR.ca / DDF or any aggregator feeds.

• CRM and showing-scheduler vendor names (e.g., kvCORE, ShowingTime) and a test account or API contact.

• A list of the minimal fields the AI should announce on calls (recommended: price, status, open-house time, agent name).

• Agreement to the vendor licence / data-use form the MLS requires (we’ll prepare the draft and routing instructions).

• A single brokerage contact who can approve sandbox and production credentials.

How you’ll see progress and proof (what a pilot/demo looks like)

• Live demo of inbound calls showing: fast listing lookup, booking a test showing, SMS confirmation, and CRM lead appearing with the listing reference.

• Pilot run on a staging number so real schedules aren’t disrupted; call recordings and sanitized call logs for review.

• Clear KPIs we track and report (calls answered, lookups that returned live data, bookings created, CRM write success, agent feedback).

• A pilot report that shows representative calls, issues fixed, and recommended next steps or rollout readiness.

Deliverables you’ll receive (handy and non-technical)

• One-page project plan with required approvals and who does what.

• A vendor request packet (email + checklist) you can send to your MLS board and broker-of-record.

• Demo script + three sample call recordings for stakeholders to review.

• Pilot report with KPIs and ROI snapshot (cost per booking vs current answering service).

• Agent playbook (how to treat AI leads, handoff script, and common FAQs for staff).

• Support & escalation contact details for Peak Demand.

KPIs and outcomes to evaluate success

• % of inbound calls answered by the AI (coverage).

• Live lookup success rate (how often MLS returns within the live path).

• Bookings per call (number of showings booked via the AI).

• Lead write success to CRM (accuracy and completeness).

• Agent satisfaction (simple survey: did you get better quality leads?).

• Cost comparison vs current after-hours answering service.

Frequently Asked Questions Brokerage Owners Have About MLS Integrations into Voice Agents

Q: Will the AI read private or restricted MLS info?
A: No — we only announce fields your MLS permits and your brokerage approves. We build guardrails so restricted data is never spoken aloud.

Q: Do we have to give the vendor full access to everything?
A: No — you control which fields and which MLS boards the vendor can access. We request only what’s needed for live calls and booking writes.

Q: Will this disturb agents’ calendars?
A: No — pilot runs use test calendars and we only wire production calendars once you confirm. Bookings are created per your business rules (holds, confirmations, agent approvals).

Q: What if an MLS denies access or has tight rate limits?
A: We handle that operationally — we recommend sensible fallbacks (text confirmations, short cache windows), and we work with boards to get the approvals you need.

How Peak Demand proves credibility (what we show you)

• Demo connecting a phone call → live MLS lookup → booking → CRM write (live, in front of you).

• Pilot report with real numbers and sanitized call samples.

• A clear vendor request packet and an onboarding checklist so your broker-of-record sees we’ve thought through governance and compliance.

Next steps (easy, owner-friendly)

1. Approve Peak Demand to prepare the vendor request packet and broker email.

2. Nominate the brokerage contact who will approve credentials and sign vendor forms.

3. We’ll produce the demo materials and a simple pilot acceptance checklist for your review.

4. Book a short discovery call with Peak Demand to review the packet and schedule the demo.

Learn more about the technology we employ.

Network with us on LinkedIn

SCHEDULE DISCOVERY CALL

Peak Demand’s AI Receptionist for real estate brokerages is the cost-effective replacement for your after-hours answering service tailored to brokerages. When a buyer calls, the system can look up the property in MLS, read accurate listing facts, ask qualifying questions, and either book a showing or route the caller to the right agent. You get fewer missed opportunities, better lead qualification, and lower call-handling costs. We handle MLS integration, CRM syncing, calendar holds, and compliance so your team can focus on closing.