ResidentAxis

Feature

Leasing and applicant workflow

From application to signed lease to renewal, in one pipeline — with the status machine, consent gates and audit trail you need when a decision is questioned later.

The problem

Applications arrive in email, screening happens in another tab, and the lease is typed from memory.

That gap is where fair-housing exposure, missed guarantors and wrong deposit amounts come from. The applicant record, the decision and the lease should be one continuous thing.

  • Co-applicants and guarantors are tracked in a thread, not a household.
  • Income-to-rent rules are applied inconsistently between leasing agents.
  • Decisions are not recorded with a reason, so adverse-action steps are missed.
  • Renewals start too late because nobody sees the 90-day window.

The workflow

A pipeline with rules at every gate

  1. Application submitted

    A household with co-applicants and guarantors, duplicate detection, and per-party consent capture.

  2. Qualification

    Household income against your rent multiple, missing-document flags, and a queue for the leasing agent.

  3. Screening

    Orders per party through a pluggable provider with payer choice; see the screening page for what is live versus configured.

  4. Offer and decision

    Offers with fees on the ledger; approve, deny or hold with a recorded reason. Denials surface the adverse-action reminder.

  5. Approve → resident + lease

    One action converts the applicant into a resident and a pending lease in a single transaction, ready for the lease builder.

  6. Renewal

    Renewal offers with accept / counter / decline and generated notices — seeded automatically from revenue signals if you enable them.

Illustrative application queue. Income multiples and stages come from the application status machine.

Capabilities

What is built, what needs configuration, what is planned

Each row is a real capability in the current build. Labels are derived from the codebase and its test suites, not from a roadmap deck.

How to read the labels

Built
Implemented in the current build and covered by its test suite.
With configured integration
Implemented; a live outcome requires a provider you configure (keys, contract, or credentials).
Pilot
Implemented in part and enabled per pilot customer with tuning.
Planned
On the roadmap. Not sold or promised today.
  • Multi-applicant applications

    Built

    Households with co-applicants and guarantors, a status machine (submitted → screening → decided), duplicate flags and income-vs-rent checks.

  • Offers and application fees

    Built

    Offer records, a review queue and application fee handling tied to the charges ledger.

  • One-step approve → resident + lease

    Built

    Approval converts the applicant into a resident and a pending lease inside one transaction.

  • Renewal offers, counters and notices

    Built

    Renewal offers with accept / counter / decline and generated notice PDFs.

  • Leasing CRM (guest cards, tours, lead sources)

    Planned

    Prospect pipeline ahead of the application step.

By role

What each party gets

Leasing agents

A queue with the next action on every application and rules applied the same way every time.

Property managers

Decisions with recorded reasons and a complete trail from application to lease.

Applicants

A clear status, consent they actually gave, and an offer that matches the lease they sign.

Configuration and pilot notes

Before you rely on it

Things that are set up per operator during a pilot, or that depend on a provider you contract.

  • Income multiples, application fees and decision reasons are configured per operator.
  • Live screening reports require a consumer-reporting-agency integration; the build ships a deterministic mock provider.
  • A leasing CRM (guest cards, tours, lead sources) ahead of the application step is planned, not built.

Questions about this area

Can applicants apply online without an account?

Applications are created by staff or through the resident-facing application flow; the public listing page links to it. A full prospect CRM with self-serve guest cards is on the roadmap.

How are application fees handled?

Fees post to the charges ledger like any other charge and are collected through your configured payment rails; who pays a screening order (applicant, owner or management company) is a per-order choice.

See leasing & applicants on your portfolio.

A pilot starts with a discovery call and your CSV exports. We reply within two business days.