When a contract is the right tool

The default for maintenance work is reactive: a tenant reports an issue, you create a ticket, you find a vendor. That works for one-off repairs but breaks down for predictable recurring work — quarterly HVAC service, monthly landscape visits, quarterly pest control. The work was always going to happen. Recreating the same ticket four times a year is operational waste.

A contract collapses that loop into one setup. Define the cadence, pick the properties, choose the vendor, set the prepaid terms — Goodtenant handles the rest. Tickets spawn on schedule, the vendor sees one batched magic link per cycle, and you only hear from us when something stalls or a cycle wraps.

Use a contract when:

  • The work is genuinely recurring (every 1, 2, 3, 6, or 12 months)
  • The vendor relationship is stable enough to commit to terms upfront
  • You'd rather spend mental cycles on judgment calls than coordination

Skip a contract when:

  • The work is a one-off emergency repair (use a reactive ticket instead)
  • You haven't worked with the vendor before — do a few reactive tickets first to vet them
  • The property doesn't have an active tenant — there's no one to confirm visits, so cycles stall before they start

The four decisions you will make

The wizard walks you through 4 steps, but conceptually you're making four decisions that shape how the contract behaves.

1. Vendor + scope

A contract is a relationship, not a recipe. You're committing to a vendor for a stretch of time across a defined set of properties. Pick a vendor you'd trust to walk into your tenant's home with reasonable notice — because they essentially will, every cycle.

Scope is the second half of this decision. A single contract can cover one property or a dozen, but every property in scope gets a ticket every cycle whether you want it or not. If your needs differ across properties (e.g. one has central HVAC, one has window units), use two contracts instead of one — the cadence, prepaid amount, and drift thresholds will all be wrong for at least half the properties otherwise.

When your portfolio exceeds 5 properties, the wizard adds a search input so you don't scroll. Use it.

2. Cadence

Pick from every 1, 2, 3, 6, 12 months. The right choice depends on the work:

  • HVAC — quarterly (every 3 months) is the industry standard
  • Landscape — monthly during the growing season; stop and restart the contract seasonally rather than picking a longer cadence year-round
  • Pest control — quarterly for general prevention, monthly if you've had recurring infestations
  • Pool / spa — monthly during use season
  • Fire alarm / smoke detector inspection — annual (every 12 months)

Be opinionated. Operators who pick "monthly because more is safer" end up paying vendors to do nothing half the time and burning out the relationship. Operators who pick "annually because monthly feels like overkill" end up reactive when systems fail mid-cycle. Match the cadence to how often the work actually needs to happen.

3. Compensation

Prepaid amount + period. Three options:

  • Per year — a flat annual amount regardless of cycle count. Use this when the vendor agreed to a fixed yearly fee. Common for HVAC service plans.
  • Per cycle — charged each time a cycle spawns. Use this when payment is tied to actual visits. Common for landscape and pest control.
  • One-time — charged once at activation. Use this for short-term contracts (e.g. a 6-month landscape contract paid upfront).

This is the number the vendor sees on their activation page. When they click the magic link in the activation email, they review these terms and either accept or decline. Be honest about the amount — a low number will get politely declined, a high number breaks your budget.

4. Window + spawn lead

These two settings answer different questions about the same calendar.

Spawn lead (default 14 days) answers "how much warning does the vendor need to schedule?" Tickets appear in the vendor's queue this many days before the cycle window opens. Bigger lead = more time to coordinate with tenants. The default of 14 is fine for HVAC and landscape; bump it to 21+ for vendors who book out far in advance.

Window length (default 30 days) answers "how long does the vendor have to finish every visit in the cycle?" The cycle window closes this many days after it opens. Bigger window = more forgiving when tenants reschedule. Smaller window = tighter SLA. The default of 30 works for most service categories; shrink it for time-sensitive work like seasonal HVAC switchover.

Drift alerts use both numbers — they fire when visits aren't progressing toward window close fast enough.

What happens after the vendor accepts

The mental model: you set the contract terms once, then you mostly stop hearing from Goodtenant until something requires judgment.

Here's the lifecycle in order:

  1. Activation. The vendor clicks the magic link in the activation email, reviews the terms + the vendor agreement template, and accepts. The contract status flips to active. You get a confirmation email.
  2. First cycle queued. A cycle is created in pending_spawn state. The spawn cron picks it up 14 days before the window opens (or whatever you configured).
  3. Tickets spawn. One ticket per property in scope. Each ticket carries the contract + cycle IDs so it's clearly part of the contract, not a reactive issue. The vendor gets one batched magic link covering every ticket in this cycle.
  4. Vendor schedules. From the cycle dashboard, the vendor proposes visit times per property. Tenants confirm or counter-propose. Confirmed visits show up on the vendor's calendar — they can download an .ics file of the whole cycle and import it into Google / Apple / Outlook.
  5. Visits happen. Vendor marks each ticket complete after the visit. Tenant verifies the work was done.
  6. Cycle closes. When every ticket is completed (or the window passes), the cycle transitions to completed, partial, or missed. You get a close summary email with the delivery numbers.
  7. Next cycle spawns. Same loop, on schedule, until the contract reaches its end date or you end it manually.

The whole middle is hands-off. You hear from Goodtenant at the bookends — first-cycle spawn confirmation, cycle close summary — and only mid-cycle if drift fires.

Drift alerts — your safety net

The headline value. Drift detection runs daily and catches seven failure modes before the cycle window closes:

  • Vendor delay — the vendor hasn't proposed any visit times yet and you're past the spawn lead window
  • Tenant non-confirmation — the vendor proposed times but the tenant hasn't picked one
  • No-show — scheduled visit time passed without a status update
  • Chronic reschedule — a single visit has been bounced more than three times
  • Vendor declined visit — the vendor opted out of a specific property visit (e.g. tenant refused entry)
  • Window close imminent — cycle window closes soon and visits are still incomplete
  • Window missed — window closed with undelivered visits

When any of these fire, you get one email per cycle per day — grouped, not spammy. The email tells you what's stuck, who's stuck, and surfaces the vendor's contact info so you can call them directly if you want.

The threshold matters. The default of 7 days before window close is calibrated for typical service work. Tighter than that and you'll get alerts for vendors who would have finished on time. Looser than that and you'll find out the cycle missed when the close summary lands.

When too tight is the wrong call: a 1-day threshold on a monthly landscape contract guarantees an alert every cycle, because landscapers don't run a tight calendar in season. When too loose is the wrong call: a 14-day threshold on a 30-day window means you find out something's stuck halfway through with no time to recover.

Common mistakes

The mistakes that show up most often, ranked by how much pain they cause downstream.

  1. Window too short. A 7-day window for HVAC quarterly means the vendor has 7 days to hit every property. One delayed visit cascades. Default to 30 unless you have a specific reason to shrink it.
  2. Forgetting to mark Year 1 paid. For per_year contracts, the anniversary cron only spawns the next-year Expense after the current year's row is marked paid. If you never click "Mark as paid" on the Year 1 row, Year 2's expense never gets created — and you find out at renewal time.
  3. Creating a contract on a property without an active tenant. No tenant means no one confirms the vendor's proposed times. Drift fires, cycle stalls. Either skip the property or wait until the tenant moves in.
  4. Picking a vendor without confirming their email. The whole activation + cycle-ready flow runs off the vendor's email address. If it's wrong, the vendor never gets the magic link and the contract stays in pending_activation forever. Send a test email before you create the contract.
  5. Not configuring a vendor agreement template. Contracts can't activate without one — the activation page renders the agreement inline for the vendor to accept. Set this up under Settings → Templates before you create your first contract.
  6. One contract covering wildly different scopes. "Quarterly maintenance for everything across all 8 properties" sounds efficient and fails in practice. The vendor's schedule, the prepaid amount, and the drift detection are all wrong for at least half the properties. Split into multiple contracts by category and cadence instead.

Once you've set up your first contract, the AI summary button at the top of this page can give you a personalized version focused on what's most relevant to your specific portfolio (paid plans). And if anything in this article stops matching how Goodtenant actually behaves — that "Last verified" date at the top is the first thing to check.