Skip to content

Trust and verification

What the system actually enforces

A product that emails listing agents on your behalf, collects a signature on a representation agreement and texts your clients has to answer for itself. This page is that answer, and it is written to one rule: a claim only appears here if there is a mechanism behind it that we can point at.

Where the mechanism covers less than the claim would suggest, the card says so. There is a section near the bottom about the thing we are careful with rather than proud of.

What this page is, and what it is not

It is

  • A list of behaviours the product enforces on itself, each one named by the mechanism that enforces it.
  • Written for a managing broker deciding whether an office can use this, and for a listing agent deciding whether to answer an email.
  • Deliberately short. Things we could not verify are not here.

It is not

  • A security page. There are no certifications, no uptime figures and no statements about who can read what.
  • A compliance opinion. Your obligations as a broker are yours, and no software claim changes them.
  • A substitute for the Privacy Policy, which is the document that governs.

Ten claims and the mechanism behind each one

Read the headline for the claim and the second half of the card for how it is held up. If the second half were removed, the card would come off the page.

Everyone here is a licensed agent

An agent account cannot start a plan or a trial, invite a client, build a tour, send a buyer agreement or claim a routed lead until the license behind it is verified. Before that, the account can browse and finish its profile.

How it is enforced

One shared verification check sits in front of those actions. If the account is not verified, the action stops with a Verification Pending message instead of going through. Verification happens one of two ways — the license number is matched against the MLS agent record, with the agent's own name cross-checked against the name on that record, or an admin approves the account by hand.

The check runs in the app, at each of those buttons. It is a product gate, not a claim that the API refuses. One outbound action sits outside it today: inviting another agent to a team is not verification-gated.

Consent, logged

Turning text messages on, and turning them off again, both leave a record. Neither is a silent state change.

How it is enforced

Every flip of an SMS switch — the master control and each individual category — writes a consent row before the preference itself is saved. The row carries who changed it, the channel, whether it was an opt-in or an opt-out, where in the product the change was made, and the time it was written. Turning SMS on when every category was off also stamps a consent date on the account.

Of the five notification categories, Updates & Marketing is the one whose push channel ships switched off. You turn that one on; you do not have to find it and turn it off.

Preferences that stop the message

A push category switched off is not filtered out on your phone. The check runs on the server, and it decides whether the push is handed to the delivery service at all.

How it is enforced

The send function reads the recipient's stored preferences server-side, maps the notification type to its category, and only queues a push when that category is on and the device has a token. Everything else is recorded as skipped, with the reason. Lead routing goes further: if the recipient's record cannot be read at all, that agent is skipped rather than notified.

Two limits worth stating. The preference governs the push to your device, not the record — the item still appears in your in-app notification list. And a showing request emailed or texted to a listing agent about a specific property does not run through this check; nothing in the product gates email or SMS on notification preferences.

One person cannot notify a stranger

Notifications a person triggers can only reach people they already have a relationship with in the product.

How it is enforced

A send started by a user is checked against a list assembled at that moment: their own account, their agent, an agent's own clients, the participants of the specific tour in question, and the agents on their teams. A recipient outside that list is dropped and counted, not delivered.

Signature evidence, without keeping the address

A signed buyer agreement records who signed, when, and from what — and the signer's IP address is not part of what is kept.

How it is enforced

At the moment of signing, the address is reduced to a one-way SHA-256 hash and only the hash is stored. Two records can be compared; neither can be turned back into an address. Stored beside it: the signing timestamp, the browser or app identifier, and device details.

In-app signing is an add-on rather than part of the entry tier. Nothing is purchasable during beta.

A full event log per agreement

The history of an agreement is not reconstructed from the document. It is written down as it happens.

How it is enforced

Each agreement accumulates its own event rows — draft created, sent, field values submitted, signed, partially signed, fully signed, voided — with the actor and the time on each. The finished PDF also carries its own Signing Certificate page: the agreement id, the completion time in UTC, and each signer by name with their signing status.

Support cannot spend your money

When support opens your account to reproduce a problem you reported, the two controls that move money are closed to them.

How it is enforced

Starting a checkout and opening the billing portal both test for an active support session first and refuse, with the message naming whose account it is. The checkout refusal points support at an internal tool that grants a subscription on the record instead — a different action, taken as themselves.

Billing is not switched on during beta, so there is nothing to charge today. The block is in the code ahead of that, not planned for later.

You cannot quietly cancel on a listing agent

Deleting a tour that other people have already committed to is not a silent operation, and the system will not let it become one.

How it is enforced

A tour carrying a confirmed showing, a confirmed client or recorded feedback takes the strict path: you type DELETE to confirm, and the cancellation notices are sent before anything is removed. If that step does not come back successful, the tour is not deleted and you are told to try again.

The notices go to the listing agent on each committed stop and to the clients on the tour, by email, with an in-app notification to the clients as well. What blocks the delete is the notification step itself failing; a single address that bounces is recorded rather than surfaced to you.

Delivery you can have checked

The messages the product sends on your behalf are written down with their exact body — not a summary of it, and not only the ones that worked.

How it is enforced

Every email goes out through one shared sender that writes a row either way, and the showing-request texts and the push notifications write the same row. Each row holds the channel, the recipient, the subject, the exact body text, which function sent it, and whether it was sent, failed or was skipped — with the provider's message id where there is one and the error text where there is not. Rows are indexed by recipient, channel, type and time.

That archive is a support tool, not a report in your account. It covers product messages; the one-time codes the login system texts you are not in it. It means a question about a specific message has an answer on file rather than a guess.

Your buyer is not named in the showing request

The showing request a listing agent receives identifies you. It does not identify your client.

How it is enforced

The request is built from the buyer agent's name, brokerage and contact details plus the property, the requested time and a link to answer. There is no client-name field in the template to fill in, by email or by text.

More detail on the notification layer specifically — the five categories, the three channels and what your phone's own settings override — is on the notifications page.

What we are careful about

Share links do what links do

A tour, an itinerary and a listing can each be opened from a link, over HTTPS, by whoever is holding it — with no account and no app. That is the design and not an oversight. A listing agent should not have to sign up to answer a showing request, and a buyer should not have to install anything to read where they are going on Saturday.

The link carries a long identifier that is not sequential and not guessable, which is what stops someone from stumbling onto a tour that is not theirs. That is the whole of the protection, and we would rather write it down than let it be inferred.

What we do not claim about these links

  • We do not claim they expire. They do not. There is no expiry on a tour or listing share link anywhere in the product, and nothing counts down.
  • We do not claim they are single-use. Nothing marks a link as spent. It works the second time, and the twentieth.
  • We do not claim forwarding is contained. A link that gets forwarded works for whoever receives it, exactly as it worked for the person who sent it.

So treat a tour link the way you would treat any link you text somebody. That is the honest shape of it, and knowing it is worth more than a reassuring sentence that would not survive a real question.

The counterpart to this is the reason it exists: a listing agent answers a showing request without an account, which is the single biggest reason requests get answered at all.

Where the product actually is

About Time Tours is in beta. It is published on the App Store and Google Play and real agents run real tour days through it, which is a different thing from finished.

Billing
Not switched on. Nothing described on this page is something you can buy today, and no page on this site quotes a plan price.
Listing coverage
Oregon, from one feed. Not a national data set, and not described as one anywhere we control.
Everything else
Answered plainly on the FAQ — what a client has to install, what a listing agent has to do, what happens offline, and how to delete an account.

Read the FAQ

FAQ

Coverage, cost, beta status, what a client has to install and what a listing agent has to do. Every caveat this page implies is spelled out there.

For listing agents

You received a showing request and want to know what it is before you answer it. That page answers it faster than this one.

For brokerages and teams

Office-level questions — rollout, onboarding a roster, and who to talk to about a whole brokerage rather than one agent.

Privacy Policy

The legal document. What is collected, why, and how to ask us to stop. This page describes mechanics; that one governs.

Bring the hard questions

If you are the person who has to sign off on an office using this, the useful conversation is the one where you ask what is not on this page. We would rather answer it than have you find the gap yourself in month three.

Support questions, including anything about a specific message that was or was not delivered, go through the support page.