Real Estate Ops
Acquisitions and property work, in one system.
Deal leads live in one inbox, tenant requests in another, and vendor invoices in a spreadsheet. Run both sides as workflows that share contacts and hand work to each other.
How it usually goes
Deal leads arrive from mail, calls and a form, and get worked from whichever inbox someone opened first.
Property requests and acquisitions live in different tools that know nothing about each other.
A repair gets done, and the invoice for it turns up three weeks later with no link to the job.
Acquisitions: the workflow you'd draw
Screening is a branch on the numbers you underwrite on. Pursuing a deal is a human decision the workflow stops for.
The lead arrives
From an email you route in a click, or typed up after a call. The Real Estate Acquisitions template already carries the fields: property address, seller, asking price, estimated ARV, repair estimate, lead source, motivation notes.
Screen it
A branch node tests the numbers you actually underwrite on (asking price against ARV, repair estimate, region, seller situation), combining conditions with All or Any so a marginal deal takes a different path from an obvious one.
Reach out
A send-email step goes out from your real mailbox with the property details interpolated in, threading properly so the seller's reply lands back on the deal.
Wait for the seller
Waits for a personAn await-reply gate holds the deal while the ball is with them. A timeout edge fires the follow-up, and a loop node caps the chase so a cold seller exits rather than being emailed indefinitely.
Approve pursuing it
Waits for a personBefore an offer goes out, the deal parks for a human decision with all the captured numbers on one screen. Rejected takes its own edge, so a pass is recorded rather than forgotten.
Resolve with the outcome
Won, denied, cancelled, no action needed. Counting passes separately from losses is how you learn which lead sources are worth the spend.
Every number that matters, then a decision
The acquisitions template captures the fields you would otherwise keep in a spreadsheet (address, asking, ARV, repairs, motivation), and the deal parks for a person before an offer goes anywhere.
The other half of the business, same engine
Tenant and vendor requests run as work orders in their own workspace: triaged, approved, dispatched, checklisted, photographed and closed, and the finished job opens the invoice in Accounts Payable by itself.
Property ops: the shorter one
Four steps, because a repair is a simpler shape than a deal.
Tenant or vendor reports it
The request arrives by email into a shared inbox, and routes into the property workflow.
Triage and approve the spend
Waits for a personBranch by trade and urgency, then park at an approval gate above your threshold, the same shape as any work-order process.
Dispatch, checklist, photos
Waits for a personThe vendor is emailed, the on-site checklist gates completion, and before-and-after photos park for someone to confirm.
Hand the invoice to AP
When the job resolves, a cross-workflow node opens the invoice ticket in your Accounts Payable workspace with the fields carried over, and one repair never bills twice.
What comes with it
Deal fields that already exist
The acquisitions template ships with property address, seller name and contact, asking price, estimated ARV, repair estimate, lead source and notes, plus stages from New Lead through to Assignment. Change any of it.
Categorise the way you think
Tag sets for seller situation, property type, outreach status and deal type come with the template, and the whole taxonomy is editable per organization.
Two operations, one system
Acquisitions and property management are separate workspaces with separate workflows, boards and analytics, but they share contacts, and a cross-workflow node lets one start work in the other.
Sellers, tenants and vendors in one book
The contact book is org-wide with a category tree and roles. Open a contact and see every ticket, email and note exchanged with them across every workspace you can access.
Property work is just a work order
The same engine that screens a deal dispatches a plumber (triage, approval, checklist, photo gate, resolve), so you are not running two products.
Which source and which stage
Tickets by channel and source, resolve outcomes, and per-node dwell time show where deals stall and which lead source actually converts.
The most fully seeded template, and still just a template. Real Estate Acquisitions ships with its own fields, stages and tag sets, which makes it a good concrete example. But nothing about property is hardcoded in RouteWrk: the same nodes, gates and boards run a helpdesk or a hiring pipeline, and you are expected to bend this one until it fits how you actually buy.
Other ways teams use it
Run the deals and the doors from one place.
Start free with the acquisitions template and make it yours.