Visitt: what the technical evidence adds
Five-minute team brief · Published October 13, 2026 · Source snapshots October 11–12
AI-generated recommendations for discussion. These are not Nick’s recommendations or approved JLL/PRISM guidance.
The investigation adds detail behind Visitt’s feature labels: conditional work-order acceptance, booking conflict handling, charge verification before accounting sync, and human controls around several AI features. This is useful for preparing a sharper demo and comparison. It does not establish which features a customer has enabled, how reliably they work, or whether PRISM is better.
Full technical dossier · Search the technical records · Existing workflow reference · Download Markdown
At a glance
| Discussion | Why it is worth testing | Evidence |
|---|---|---|
| Booking conflicts | Understand the staff decision and affected reservations | CW09 |
| Charges to accounting | Separate approval, sync eligibility and the ledger result | CW10 |
| Offline inspections | Check whether completed work survives restart and reconnection | Offline inspection finding |
| AI correction | Measure how people catch and repair a wrong result | CW05 |
| Roles and configuration | Establish what the specific customer can actually use | CW01 |
What matters for a competitive conversation
1. Compare the whole booking exception, not just the reservation form
What the client shows. The manager form queries availability and costs, validates custom questions, and can present a server-reported overlap in a conflict dialog. The confirm action resubmits with an explicit option to cancel overlapping inquiry bookings. The tenant portal has separate booking creation, edit and cancellation paths.
Why it matters. A standard happy-path demo would miss inquiry handling, conflicting requests and staff intervention. Those are better comparison points than a shared “amenity booking” checkbox.
Suggested demo test. Use the same room and time in two authorized test sessions. Show the inquiry, conflict message, staff decision, affected booking statuses and tenant notification. Then compare cancellation and any charge adjustments with PRISM. Concurrent server protection, payment and refund outcomes remain unverified here.
Evidence: Manager booking rules, CW09, tenant booking, W16, edit/cancel, W17. Open the existing amenity workflow.
2. Follow a charge all the way to the accounting result
What the client shows. Charge arithmetic, verification, billing-tenant selection, eligibility for sync, and the sync request are separate steps. Moving selected verified charges to “awaiting sync” does not demonstrate successful posting to an external ledger. The tenant portal also has a charge-approval path with a drawn signature.
Why it matters. The operational burden often sits between approval and reconciliation. The evidence gives the team concrete states to ask about, without claiming an accounting defect.
Suggested demo test. Trace one taxable charge through approval, the correct billing tenant, export or sync, the external accounting entry, a failed attempt and recovery. Compare where staff intervene and what audit evidence remains. Server-side posting, retries and ledger reconciliation are unknown from this analysis.
Evidence: Charge and sync flow, CW10, tenant approval, W14. Open the billing workflow.
3. Distinguish offline viewing from reliable offline completion
What the client shows. A gated mobile inspection path prefetches open inspections; an inspection page can render cached items offline. The reviewed code did not establish a durable queue that safely replays inspection mutations after reconnection.
Why it matters. Cached access and completed-work recovery answer different field-team needs. The missing replay evidence is a question to validate, not proof that Visitt lacks offline completion.
Suggested demo test. Load an inspection, disconnect, change answers and add a photo, restart the app, reconnect and inspect the final server record. Include a competing edit and a failed upload. Apply the same test to PRISM before making a differentiation claim.
Evidence: Prefetch conditions, cached rendering and replay limit. Open the inspection workflow.
4. Assess AI by the correction path and outcome
What the client shows. COI extraction has polling, retry, manual field overrides and a separate approval action. Text enhancement retains an original for undo/retry. Tenant request category suggestions are optional and manually overridable.
Why it matters. These are concrete human-control patterns. “We also have AI” is a weak comparison; correction effort and resulting workflow accuracy would be more useful measures.
Suggested demo test. Use the same authorized test documents or requests across products, include ambiguous inputs, and observe how a user catches and corrects a mistake. Record elapsed time and the final saved result. The underlying AI models, prompts, accuracy, retention and server validation are not established by the shipped client.
Evidence: COI extraction and approval, CW05, text undo/retry, CW06, category override, W09. Open the AI workflow.
5. Ask which role and configuration the demo represents
What the client shows. Acceptance, automation choices and several AI surfaces depend on explicit feature or assignment conditions. Installed mobile releases and current hosted frontends are separate snapshots; an additional update layer may change what runs.
Why it matters. A feature in a client catalogue does not tell us its commercial packaging, tenant configuration, access policy or current rollout. These differences can explain why two customers describe different experiences.
Suggested demo test. Record the app/version, tenant settings and user role, then repeat the relevant exception as a tenant and an operator. Ask the vendor to identify enabled features and required configuration. This research does not establish pricing, entitlements or complete server authorization.
Evidence: Acceptance conditions, CW01, automation conditions, CW04, portal configuration, W05, release distinction, W25.
What was verified—and what was not
The source investigation reports an independent audit of 125 retained findings and repeat analysis of five representative native functions in fresh Ghidra databases, with matching compared outputs. This publishing host checked the pinned transfer, references and integration; the raw binaries were not available here for another independent code audit.
Two account-entry observations used the same newly generated identifier, one request in each app. Both returned an unrecognized-account message. There was no successful login, authenticated workflow, private customer data, deliberate GraphQL operation, business mutation or upload. Email delivery was not established. These tests say nothing conclusive about invitation-based or sanctioned evaluation access.
The evidence inventory contains 125 findings, 848 client API variants/documents, 120 selected route declarations, 20 client-selected model families, 67 selected native-function records and 488 provenance records. These are evidence counts, not feature counts. Library inclusion does not by itself establish an exposed product feature. Visitt+ remains labelled separately within Visitt company records.
How the team can use this today
For the presentation, use the five comparisons above and choose the two most relevant to the deal. Open the linked workflow for its existing UI evidence, then the technical finding for the narrower implementation observation. Agree which demo result would change the team’s view before drawing a conclusion.
For engineering or an AI assistant, the record browser exposes every finding, API entry, route, model and provenance record. The existing read-only MCP supports these same stable IDs. For example:
get_workflow({"workflow_id":"visitt-amenities"})
get_record({"record_id":"visitt-rea:finding:cw09"})
search_research({"query":"offline inspection","company":"Visitt","kind":"technical_finding"})
get_document({"document_id":"visitt-rea-technical-dossier.md","offset":0,"limit":12000})
Follow returned pagination until complete. Preserve each record’s app, date, source coordinates and evidence status. Have the assistant verify private PRISM capabilities against your own authorized product context; this site does not connect to that context.
What belongs in a private technical archive
An access-controlled archive could help an engineer reproduce the investigation with original artifact hashes, tool versions and the relevant source files. A shared password would limit casual access but would not by itself make raw binaries, full source mirrors or any embedded configuration suitable for publication. They add little to the team presentation. The public package therefore includes normalized records, source URLs or withheld-artifact identifiers, hashes, coordinates and limitations; it excludes raw binaries and complete decompiled source.
This supplement is a dated investigation, not an automatically repeated reverse-engineering job. September reports keep their original dates. Daily reviews and weekly public monitoring remain separate processes.