This describes work that is in design. Everything below is what we are building, not something you can switch on today.
Two things happened at the same firm last week and neither of them is on any list.
On Tuesday somebody asked about the two-bedroom, sounded genuinely keen, and then went quiet. Nobody chased them. Not through negligence — chasing is a discretionary task, discretionary tasks live at the bottom of the day, and the week filled up the way weeks do.
On Thursday somebody started the screening form and stopped halfway. Nobody knows this, because a half-finished form does not appear anywhere. It is not a lead, it is not an application, it is not a task. It is an absence.
Both of those people were warm. The firm paid to acquire both of them — in advertising, in listing time, in the reply somebody wrote. And it lost both to admin rather than to a competitor.
Now the other half, because everyone reading this has been on the receiving end: every operator can name the tool that chased somebody four times after they had already replied. That is the version of this feature everybody has met, and it is why "follow-up automation" is a phrase that makes people wince.
So this is a piece about doing the first thing without becoming the second.
The two design decisions that carry it
Cadence is code, and the model only writes the words
How many follow-ups, how far apart, in what tone — that is your firm's decision, it lives in your configuration, and it runs as deterministic code. Two messages, four days apart, warm. Or one, after a week, brisk. Whatever you set.
What the model does is write the words inside that structure — this unit, this person, this context, your voice. It does not decide whether to send or when.
The reason is simple: a follow-up schedule that depends on a model's judgement about whether now is a good moment is a schedule that will eventually send a fifth email. Not usually. Not predictably. Occasionally — which is worse, because you cannot reproduce it and you will not find out until somebody tells you what your firm did.
A schedule in code does the same thing every time. You can read it, change it in a minute, and know what it will do next Tuesday.
Stop means stop, enforced in the send path
This is the one that matters, and it is the reason this piece exists.
When somebody replies, or asks not to be contacted again, the sequence ends. Not "the model notices and adjusts" — ends, at the point of sending, before any message can go out.
The distinction is everything. If stopping depends on a classifier reading intent correctly, then stopping is a probability. Most of the time it works. Occasionally somebody writes "thanks, we've found somewhere — good luck with it" and a model reads warmth instead of closure, and your firm sends a fourth email to somebody who politely said no.
A stop that depends on interpretation fails open, and failing open is precisely the behaviour that made this whole category of software unwelcome. So it is not built that way. The send path checks whether the thread is stopped, and a stopped thread cannot emit a message, no matter what any other part of the system concluded.
That is a boring piece of engineering and it is worth more than any amount of cleverness above it.
The other end: when a unit comes back
The same principle applies to the warmest list a firm ever has.
A unit falls through — the applicant withdrew, the deal did not close, somebody gave notice again. The people who already asked about that exact property are, by a distance, the best leads available for it. They asked about that building. They know what it costs. Some of them already answered your screening questions.
Today they sit on a per-property waitlist and somebody has to remember to look. What we are designing is that they get told the hour it comes back rather than the following Monday, when whoever handles that building next opens the list.
How the order is decided, stated plainly: first in, first out, on when each person inquired. Computed in code.
Nothing else is consulted. Nobody at Releaser decides who hears about your unit first, and neither does a model — the timestamp does, and that is a property of how the thing is built rather than a policy it has been asked to follow.
That line is the same one we hold everywhere in this product: software does the collecting, the remembering and the tedious parts; judgments about people stay with you. A waitlist that decided who was worth telling first would be making one.
The trade-off: less clever on purpose
A deterministic cadence is less sophisticated than one that adapts to each person, and we are choosing that deliberately.
An adaptive sequence could, in principle, learn that this applicant responds better on Thursday evenings and shift accordingly. It might even be right. What it cannot do is let you answer the question "why did my firm email this person three times?" with anything more useful than "the system judged it appropriate."
A cadence you set is one you can audit, explain and change. You can look at it, decide two messages is one too many, and change it before lunch. That is worth more to a firm whose name is on every message than a schedule that optimises itself in directions nobody can reconstruct.
What it will never do
Three boundaries, worth stating explicitly because this is the feature most likely to be assumed into something else.
It contacts the applicant. Nobody else. Not a reference, not a previous landlord, not an employer. Not in any version, not as an option, not for a large enough customer. The only person in a conversation with your firm is the person who wrote to your firm.
It does not chase people who have replied. That is the send-path rule above, and it is the whole point.
It does not decide who is worth chasing. Everybody in a sequence gets the sequence. There is no scoring step deciding whose follow-up is worth sending, because that would be a judgement about a person and this software does not make those.
What we are not going to tell you
No open rates. No reply rates. No "recovers X% of stalled applicants."
We do not have those numbers, and the ones circulating in this category come from vendors measuring their own products under conditions nobody published. When this ships, the numbers worth looking at will be yours: how many stalled inquiries came back, at which properties, from which sequence — measurable in your own account, about your own applicants.
Until then, what we can tell you honestly is what it will and will not do. That seems more useful than a percentage.
Releaser is available to property management firms in the United States and Canada: one shareable link per property, your screening completed before anyone reaches your calendar, self-serve booking for the people who meet the criteria you set, and a waitlist on every property.
Follow-up sequences and waitlist notification are in design. This is what we are building them to be.