Build an Accommodation Request Desk Before AI Schedules Showings

AI is useful at the easy part of showing coordination: reading availability, proposing time windows, sending reminders, and updating the CRM. It is risky at the sensitive part: deciding how to handle a buyer, tenant, owner, or visitor request that touches disability, service animals, mobility limits, sensory needs, entry instructions, or other accommodation details.

That gap needs a small operating system before automation gets involved. Call it an accommodation request desk: a structured place to capture the request, separate private facts from scheduling instructions, route the question to the right human, and publish only the approved operational rule back to the AI workflow.

This is not a legal-advice workflow. It is a control that keeps AI from improvising when a person asks for equal access, a changed showing process, a service-animal clarification, or a property-entry adjustment.

Why this control belongs upstream

Real estate teams are already mixing AI into daily operations. NAR reported in its 2025 Technology Survey release that 46 percent of agents surveyed were using AI-generated content and that 42 percent used AI daily or weekly. That makes the edge cases more important, not less important. The team does not need AI to know every fair housing detail. The team needs AI to stop at the right boundary and use an approved instruction.

HUD frames its disability housing resources around the rights of people with disabilities and the responsibilities of housing providers under federal law. The DOJ and HUD joint statement on reasonable accommodations under the Fair Housing Act explains that refusing reasonable accommodations in rules, policies, practices, or services can be disability discrimination when the accommodation may be necessary for equal opportunity to use and enjoy housing. ADA.gov's service-animal guidance also makes a practical point for public-facing teams: when service-animal status is unclear in covered settings, staff are limited in what they may ask and should not request registration, certification, or medical details as proof.

Those sources point to the same operational problem. A scheduling bot should not be deciding what questions to ask, what proof to demand, or what detail belongs in a showing reminder. That decision belongs in a documented human review path.

What the desk records

The accommodation request desk is not a notes field inside the appointment. It is its own record with tighter permissions and a narrower purpose.

At minimum, capture:

• Request source: buyer, tenant, seller, listing agent, buyer agent, property manager, owner, vendor, or caregiver.
• Property and appointment context: listing ID, requested showing window, occupancy status, access method, and known property constraints.
• Request category: mobility access, service animal, communication format, sensory consideration, timing adjustment, entry-route request, parking/access path, or other.
• Operational ask: what needs to change in the showing process.
• Sensitive detail flag: whether the request includes medical, disability, family, or other protected information that should not be copied into AI prompts.
• Owner: broker, team lead, compliance owner, listing agent, property manager, or counsel.
• Status: new, needs clarification, approved instruction, declined/escalated, expired, or archived.
• Approved AI instruction: the exact non-sensitive scheduling rule automation may use.
• Audit trail: who reviewed it, when, what source document or message was reviewed, and when the instruction should be rechecked.

The most important field is the approved AI instruction. It should read like an operational rule, not a diagnosis. For example: "Use the step-free entrance on the east side and allow a 15-minute arrival window" is useful to scheduling automation. A medical explanation is not.

What AI is allowed to do

Once the desk exists, AI can help with the low-risk mechanics.

AI can suggest available showing windows that respect the approved instruction. It can remind a human owner when an unresolved request is blocking a showing. It can update the CRM status from "pending review" to "ready to schedule" after the human owner approves the instruction. It can generate a neutral note for the showing confirmation that avoids protected details. It can detect when a new message conflicts with the approved rule and reopen the desk item for review.

AI should not decide whether an accommodation is legally reasonable. It should not ask for medical records, service-animal certification, or extra proof because a model guessed that more documentation would be safer. It should not expose one client's private request to another party just because the CRM appointment has a shared notes field. It should not convert a sensitive request into marketing language, listing remarks, or a public availability constraint.

That separation turns AI from an unsupervised decision-maker into a logistics assistant working from approved instructions.

Implementation pattern

Start with one queue, one policy, and one release rule.

The queue is a table or CRM object for accommodation requests. Keep it separate from generic showing notes. Restrict access to people who need to review or execute the request. Give it stable statuses and require an owner before any request can move to approved.

The policy is a short internal playbook. It should tell staff when to open a request, what not to ask, which requests require broker or counsel review, and how to write approved instructions without exposing sensitive facts. Use official resources as reference points, but keep the playbook tied to your state, brokerage, MLS, property-management, and legal context.

The release rule is the automation boundary. AI may use only the approved instruction field, not the raw request. If there is no approved instruction, the scheduling workflow pauses and routes the item to a human. If a request changes, the old instruction expires. If the property condition changes, such as access route, elevator status, owner occupancy, or tenant availability, the item reopens.

This fits the NIST AI Risk Management Framework mindset: map the context, measure where harm can occur, manage the control, and govern who owns it. NIST released the AI RMF for voluntary use to help organizations incorporate trustworthiness into AI systems, and its 2026 updates continue to push AI risk management toward practical implementation. A small accommodation desk is exactly that kind of practical control.

The operating test

A good desk passes five tests.

First, a coordinator can identify the current approved instruction in less than 30 seconds. Second, the AI workflow can schedule without seeing protected details. Third, a request with unclear legal or policy implications cannot be auto-approved. Fourth, a client-facing message can be reconstructed from the audit trail if a complaint or misunderstanding appears later. Fifth, the system preserves dignity: the person making the request does not have to repeat sensitive information to every person touching the appointment.

The goal is not to make showing coordination slower. The goal is to make the slow part explicit. Once the team has approved a clear, respectful instruction, automation can move quickly again.

What to build this week

Create the desk with five statuses: new, reviewing, approved, blocked, and archived. Add required fields for property, appointment, request category, owner, sensitive detail flag, and approved AI instruction. Add a rule that every AI scheduling action checks the desk before sending availability or entry instructions. Add a template for neutral confirmation language. Add a weekly review for open requests and expired instructions.

Then test it against real examples from the last quarter: a service-animal question, a step-free access request, a request for a different communication format, a request involving an occupied listing, and a request that should have gone to a broker before anyone replied.

If the workflow works for those cases, connect it to the scheduling assistant. If it fails, fix the human review path first. AI should inherit a reliable process, not create one while a client is waiting.

Sources

• HUD: Information for Persons with Disabilities
• DOJ/HUD Joint Statement: Reasonable Accommodations Under the Fair Housing Act
• ADA.gov: Service Animals
• NAR: REALTORS Embrace AI, Digital Tools to Enhance Client Service
• NIST: AI Risk Management Framework