Property Preservation Software in 2026: The Complete Guide to Platforms, Automation, and AI

What is property preservation software, and what does it actually do?

Property preservation software is the work-order system a field services company runs its business on — receiving orders, dispatching crews, capturing photo evidence, building bids, tracking timelines, and producing invoices for defaulted and REO properties. It sits between the servicer or national client who issues the work and the crew who performs it, and its core job is proof: proving the work was done, on time, to specification, at an allowable price.

The vocabulary shifts depending on who is speaking. Contractors and the companies who dispatch them say property preservation. Servicers and their vendors say mortgage field services. The people who run the loans say default servicing. The software category is the same one, and this guide uses all three the way the industry actually uses them.

A complete order cycle usually runs: an order arrives from a client portal or a national order source, a coordinator assigns it to a crew, the crew performs the work and captures geocoded photos, results and photos are reviewed for quality, damages get bid, results are submitted back to the client’s system, an invoice goes out, and — often weeks later — some portion of that invoice comes back disputed. Every meaningful feature in every platform on this list exists to serve one of those steps.

What the category is not is a compliance guarantee. No platform makes a HUD timeline for you, absorbs a chargeback, or decides whether a bid is defensible. It organizes the evidence and prepares the decision — and that division of labor is the standard this entire guide holds every tool to: the system reads, drafts, flags, and tracks; your coordinators decide.

Who runs this software? The four roles in a defaulted property’s life

A single defaulted property passes through four distinct roles — the servicer, the HUD-contracted manager, the national order source, and the regional field services company that actually performs the work — and property preservation software means something different to each one. Knowing which seat you occupy determines which half of this guide applies to you.

The servicer or mortgagee holds the loan and carries the regulatory exposure. They buy servicer-side orchestration platforms and they set the rules everyone downstream follows. The Field Service Manager and Asset Manager tier exists specifically in HUD’s world: HUD contracts with FSMs and AMs to maintain and market its REO properties, and those managers push work down to subcontractors. The national order source tier — companies of the Safeguard, MCS, ServiceLink, and Five Brothers class — aggregates volume from servicers and distributes it through regional networks. And then there is the regional field services company: five to fifty back-office staff, crews in the field, orders arriving from several clients at once, invoices going out, chargebacks coming back.

That last seat is who this guide is written for, and Verisk itself names regional field services as a distinct buyer segment for its preservation products. It is worth being equally direct about who this guide is not written for. A two-person crew running orders off a phone does not have a back office to automate. There is no coordinator re-keying orders, no photo QC queue, no invoice reconciliation ritual. For that operation the honest answer is a good mobile app and nothing else. The economics of automation start where the coordination burden starts, and coordination burden starts with staff.

The secondary reader is the servicer-side default operations lead. Much of what follows about the portal gap reads the same from the other side of the table — you are the portal.

The two sides of your stack: the tools you run and the portals you answer to

Every field services company operates two software stacks simultaneously — the platform it chose and pays for, and the client portals it is required to use — and almost all the manual labor in a back office lives in the space between them. This is the single most useful frame in this guide.

On one side are the tools you run: your work-order platform, your field-capture app, your estimating tool, your accounting system. You chose them, you control the configuration, and when they annoy you, you can call support. On the other side are the systems you answer to: HUD’s P260, a servicer’s Equator instance, a national client’s vendor portal, and however many one-off web systems your client list requires. You did not choose them, you cannot configure them, and they will not change to suit you.

The gap between those two sides is where the hours go. An order lands in a client portal and a coordinator copies it into your platform by hand. A crew’s photos come back and someone reviews them against the client’s specification before upload. Results get typed into the portal a second time, in the portal’s format. An invoice gets disputed and someone reconstructs the evidence trail from three systems to defend it. None of that is skilled work. All of it is expensive.

No platform vendor owns both sides of that gap, and none of them can. Your work-order platform cannot log into a servicer’s portal on your behalf; that portal was not built for your convenience. This is the same structural pattern we documented in title and escrow in our AI for title companies guide: the incumbents automate beautifully inside their own walls, and the durable operational gains sit in the layer above, moving work between systems no single vendor controls. In this vertical that layer is what DefaultFlow is built to be.

The platform landscape: who owns what in 2026

The field services software market has quietly consolidated — Verisk now owns three of the tools you run, Altisource and Yardi operate two of the portals you answer to, and Aspen Grove sells to the servicer rather than to you. Before evaluating anything, know who owns what and which side of the stack it sits on. For the deepest cut on the market’s center of gravity — PPW’s tiers, its Pruvan integration, and what you can build on top — see our PPW deep-dive.

Platform	Owner	Side of the stack	Where it fits
Property Preservation Wizard (PPW)	Verisk (Xactware)	Tool you run	Work-order management for field service companies, lenders, and servicers
Pruvan	Verisk (Xactware)	Tool you run	Mobile field capture — certified, geocoded, timestamped photos, videos, and forms
XactPRM	Verisk (Xactware)	Tool you run	Line-item repair and preservation estimating for bids
Aspen iProperty	Aspen Grove Solutions	Servicer-side platform	Property servicing orchestration sold to servicers and asset managers
Equator	Altisource	Portal you answer to	Default and REO servicing SaaS, with dedicated portals for agents and vendors
P260	Yardi (operated for HUD)	Portal you answer to	HUD’s portal for FSMs, Asset Managers, and their subcontractors
EZinspections · InspectorADE	Independent	Tools you run	Field-side alternatives named in industry comparisons

Who owns PPW and Pruvan?

Both are Verisk products, developed and sold through Verisk’s Xactware business. Verisk describes Property Preservation Wizard as a work order management solution developed by Xactware, and states plainly that Pruvan is part of the Xactware family of products. There is a naming wrinkle worth knowing: Verisk’s current product pages lead with Property Preservation Wizard, while the propertypreswizard.com login domain and older newsroom releases use Property Pres Wizard. They are the same product, and the market usually searches for the longer form.

The third piece is the one most landscape articles miss. XactPRM is Verisk’s line-item estimating tool built specifically for the mortgage and property preservation market, and Verisk markets XactPRM Connect as a direct connection between PPW and XactPRM so estimators stop switching between platforms. Verisk’s own field-services messaging now presents PPW, Pruvan, and XactPRM as a set. So when you run “PPW and Pruvan,” you are not running two vendors’ products that happen to work together — you are running one company’s product line, which is genuinely good news for how well those pieces connect, and worth knowing when you evaluate anything that has to sit alongside them.

Pruvan prices in tiers, and the tier determines what it can connect to: Solo at $47 per month carries two premium integrations, Team at $187 carries four and adds a client portal and invoicing, and Business at $390 carries unlimited premium integrations and is the only tier that includes subcontractor management. If your coordination pain is subcontractor status, that is a tier question before it is an automation question.

(We keep this section at landscape depth. PPW’s workflow anatomy, its rules engine in practice, and what an automation layer on top of it looks like get their own guide.)

What is P260, and who has to use it?

P260 is HUD’s Yardi Voyager portal, and if you touch FHA-insured defaulted properties, you are in it. It supports the full lifecycle of HUD’s REO properties from pre-conveyance through public sale, and lenders submit pre-conveyance requests and title documents through its Lender Portal. HUD contracts with Field Service Managers and Asset Managers to maintain and market its REO inventory, and per HUD’s P260 portal documentation those managers can have their subcontractors upload items such as inspections, appraisals, and closing information through the portal. If you are that subcontractor, you do not provision yourself — you obtain access from the FSM or AM you work for, and HUD policy questions route to HUD or to that manager.

Access runs on a SuperUser hierarchy that matters more than it sounds. HUD’s P260 portal documentation requires mortgagees to designate a primary SuperUser and set up access for any vendor or agent handling property preservation and protection activity — and it reminds mortgagees that they are fully responsible for the actions of their vendors and agents carrying out actions on their behalf, which in practice means responsible for everything those vendors do in the portal. Read that sentence as a vendor: your portal work is your client’s liability, which is exactly why their QC standards feel unreasonable. The documentation also describes a monthly case upload cadence tied to accurate SFDMS delinquency reporting, and it identifies RE Global as HUD’s Mortgagee Compliance Manager, the single point of contact into which compliance documentation is scanned and uploaded. None of this is configurable by you. It is the environment.

What is Equator?

Equator is a default and REO servicing platform and an Altisource business unit, covering the lifecycle from delinquency through REO disposition and connecting servicers, investors, agents, and vendors through dedicated portals. Altisource’s current product line runs under EquatorPro. In a February 2026 announcement, Altisource said the servicer Statebridge had selected Equator to manage its REO operations, with a Statebridge executive citing the platform’s continued modernization, including new AI capabilities. For a field services company, Equator is usually not something you buy — it is something you log into because a client runs it.

Where does Aspen Grove fit?

This one deserves a straight answer rather than a logo in a grid. Aspen Grove Solutions sells property servicing orchestration — its Aspen iProperty platform — to servicers and asset managers, not to field services vendors. Its own materials describe orchestrating and synchronizing servicing operations while enabling no-code configuration, and cite more than two hundred industry integrations. Its platform also includes standardized criminal background checks for mortgage field services.

Why say this plainly: Aspen Grove is the closest thing in this market to a no-code orchestration platform, and a fair reader would ask how a custom automation layer is different. The answer is which side of the table it sits on. Aspen Grove orchestrates the servicer’s operation and the vendor network beneath it. A layer built for you orchestrates your operation across the several clients and portals you serve. Those are different problems, and neither one solves the other.

What your platform’s automation already does — and where it stops

If a workflow lives entirely inside one platform, use that platform’s built-in automation first — but check which tier you are on before you assume you already own it. This is the question a vendor will not ask on your behalf, so here it is: a meaningful share of companies reading this guide do not need a custom layer yet, and another meaningful share are paying for a plan that does not include the automation they think they have.

The incumbents are not standing still. Verisk documents a System Rules Engine inside PPW for building workflow automation without traditional coding, alongside SLA configurations, order frequency controls for managing service frequency and spending limits at the property level, and PPW Link, its API. Aspen Grove sells no-code configuration on the servicer side, and describes an AI-driven, BPMN-powered framework that lets servicers automate, track, and manage processes from routine servicing through complex default operations. Altisource is publicly marketing AI capability in Equator. The automation floor in this industry has risen, and any honest guide has to say so before it proposes building anything.

But the floor is tiered, and this is the sharpest thing in this guide. PPW publishes Premium at $199 per month for the first five users and Enterprise on request — and the System Rules Engine, the SLA configurations, the order frequency controls, and PPW Link all sit in Enterprise. Premium covers order management, reporting, photo management, dynamic forms, automated work order assignment, customizable line-item pricing, QuickBooks, and the mobile app. It does not include a rules engine, and it does not include an API. So before anyone tells you to “use what you already pay for,” find out what you actually pay for. If you are on Premium, the rules engine is an upgrade conversation with Verisk, not a feature sitting unused in your account — and pricing that upgrade is the first thing to do, because it may be cheaper than anything else on your list.

Where the built-in automation is available to you, use it. Auto-assigning work orders to the right vendor, routing by service area, enforcing spend limits at the property level, configuring an SLA — those are in-platform jobs, and the platform will do them better than an outside builder will.

The boundary appears the moment a workflow crosses a system you do not own. A rules engine cannot open a client’s vendor portal and read today’s new orders. It cannot format results to a portal’s schema and submit them. It cannot pull the evidence trail out of three systems to defend a disputed invoice. Embedded automation stops at its vendor’s walls — and in this vertical, unusually, most of your painful work happens outside those walls, because your clients’ systems are not your vendor’s systems. We worked through the same built-in-versus-custom boundary in a different regulated back office in our AI for insurance agents guide; the framework transfers, but the balance tips harder toward the layer above here, because the portal count is higher.

The standard every automation in this guide is held to: the system reads, drafts, flags, and tracks; your coordinators decide.

Where does automation pay first? Seven lanes for a field-services back office

The best first automation removes the most re-keying from the highest-frequency workflow — which in this industry almost always means order intake, photo QC, or chargeback defense, in that order. Seven lanes, each held to the read-draft-flag-track standard.

How does automated order intake from client portals work?

Intake automation watches the places orders arrive — client portals, order emails, spreadsheet drops — extracts the order details, and creates the work order in your platform with the fields already populated. The coordinator’s job changes from typing to checking. For a company pulling orders from four or five client systems every morning, this is usually the single largest recovered block of time in the building, and it is the lane most operations should start with.

Can AI check field photos before they reach the client?

Yes, and this is the lane with the sharpest financial edge. Photo automation reviews what comes back from the field against the order’s requirements — are the required angles present, is the before/after pairing complete, are timestamps and geocodes consistent with the assignment, does anything look like the wrong property — and flags gaps for a human reviewer before the package goes out. It does not approve the work. It builds the reviewer a queue sorted by risk. Since photo rejections cost you a second trip and a delayed invoice, catching them internally is money you keep.

What does automated results submission look like?

Submission automation takes a completed order and puts the results where the client requires them, in the format the client requires, without a person retyping the same information into a portal a second time. Where a client offers an API or a structured upload, the layer uses it. Where the only route is the portal a human logs into, the layer prepares the package so the human’s job is review and submit rather than transcribe. This is the mirror image of intake, and it is usually the second lane built.

How does automation help with bids and allowables?

Bid automation assembles the material a bid needs — the damage documentation, the photos, the measurements, the applicable line items — and drafts the bid for review against the client’s allowable structure, flagging anything that exceeds an allowable and therefore requires approval before work proceeds. The judgment stays human, because pricing judgment is the business. What automation removes is the assembly.

Can automation defend against chargebacks?

Partly, and the part it can do matters. A chargeback usually succeeds because the evidence is scattered or missing, not because the work was not performed. An automation layer that captures the complete record at the time of the work — order specification, timestamps, geocoded photos, completion data, submission confirmation — and can reassemble it on demand turns a chargeback response from an afternoon of archaeology into a review. Some disputes are legitimate and no system will save you. The rest are documentation problems, and documentation problems are solvable.

How does automation coordinate subcontractors?

Coordination automation handles the status loop that currently runs on phone calls and text messages: dispatching assignments, confirming acceptance, chasing incomplete results against the due date, and surfacing which orders are at risk of missing a client timeline. Check your field-capture tier first — Pruvan, for instance, gates subcontractor management to its Business plan — because the cheapest version of this lane may be a plan change rather than a build. Where it is a build, your coordinators stop being a switchboard and start managing the exceptions the system raises.

What scorecard and reporting work can be automated?

Client scorecards run your business whether you watch them or not — timeliness, quality, rejection rates, completion percentages. Reporting automation assembles those numbers from the systems where they live, on a schedule, before your client’s version of them arrives. The document-understanding pattern behind most of this is the same one we described for a neighboring mortgage vertical in our automated mortgage processing guide. Knowing your scorecard trend a month early is the difference between fixing a problem and explaining one.

What about HUD, FHA, and investor guidelines?

Treat automation the way you already treat compliance: document what it does, keep a human accountable at every decision that touches a timeline or a dollar, and hold the evidence to the standard your client’s regulator holds them to. This section is general information, not legal advice — I am a Florida attorney, and the first thing an attorney tells you is that your client agreements and the current handbook control.

Start with why the work exists at all. Under 24 CFR §203.377, a mortgagee that learns an FHA-insured property is vacant or abandoned must inspect it at least monthly while the loan is in default, must perform a visual inspection to determine vacancy when a payment is more than 45 days late and telephone contact has failed, and must take reasonable action to protect and preserve the property until it is conveyed to the Secretary. That regulation is the origin of your work order. Every initial secure, every winterization, every inspection photo traces back to a servicer discharging that duty through you.

The conveyance standard is the anchor at the other end. FHA’s Single Family Housing Policy Handbook 4000.1 — the consolidated source of FHA single-family policy, most recently updated November 26, 2025 and published through HUDCLIPS — sets specific conditions a property must meet before conveyance to HUD: that it is undamaged by the enumerated damage categories, secured and winterized where applicable, that insured damages are repaired to the approved scope, that interior and exterior debris is removed and the property is in broom-swept condition, and that the yard and grounds are maintained. Every one of those conditions is a work order, a photo set, and a deadline in your system, which is precisely why timeline tracking is not administrative overhead in this business. It is the product.

The regulations behind the process have teeth that reach past the servicer. Under 24 CFR §203.366, a mortgagee that conveys property without good marketable title must correct the defect within 60 days of notice from the Secretary; if it does not, it owes HUD’s cost of holding the property, accruing daily, plus interest on the insurance benefits already paid. And if the defect is not corrected within a reasonable time as HUD determines it, the Secretary will reconvey the property to the mortgagee, which must then reimburse HUD. A separate rule at 24 CFR §203.670 governs conveyance of occupied property, where HUD accepts conveyance only in defined circumstances. Your client lives with all of that exposure. When their QC feels punishing, this is why.

Then there is the portal reality already described: HUD’s guidance makes the mortgagee fully responsible for its vendors’ and agents’ actions taken on its behalf. An automation layer in this environment must therefore be auditable by design — every automated action logged, every human approval recorded, and nothing that alters a client-facing submission executing without a person signing off. The rule this guide has repeated holds hardest right here: the system reads, drafts, flags, and tracks; your coordinators decide. An automation that drafts and flags reduces your exposure by making work consistent and traceable. An automation that submits unreviewed manufactures it. Insist on the first kind, from any builder, ours included.

(Conveyance condition, its checklists, and its timelines get a dedicated reference guide — this section stays at the level a software decision requires.)

Buy, build on, or wait? The decision framework

Match the path to the shape of the bottleneck: built-in automation for in-platform work, a custom layer for anything that crosses a client’s system, and deliberate waiting when the workflow is not documented well enough to automate honestly. Ten common situations:

Your situation	Recommended path
Two-person crew, no back office staff	Nothing to automate yet — a good mobile capture app is the right tool
Coordinators re-keying orders from client portals every morning	Custom layer on order intake
Photos regularly returned by client QC	Custom layer on pre-submission photo review
Chargebacks arriving with no assembled evidence trail	Custom layer on evidence capture and dispute response
Single client, single portal, everything already in PPW	Price PPW Enterprise before building anything — the rules engine and API live there
Running several client portals plus a platform plus spreadsheets	Custom layer — orchestration is the actual need
No documented order-to-invoice path	Wait: document the workflow first, then automate it
Considering switching platforms to get the automation	Wait: build on what you run rather than migrating
Adding servicer or national client relationships	Custom layer — normalization at onboarding
Subcontractor status running on phone calls and texts	Check your field-capture tier first, then a custom layer for dispatch and status

Three of those rows say some version of not yet, and they are the honest ones. Automating an undocumented workflow encodes whatever chaos already exists and makes it harder to see. Migrating platforms to acquire a feature your current vendor is also shipping is expensive motion. And a company without a back office has no coordination cost to remove. When the answer is “wait,” the highest-return work is usually the documentation itself — which then becomes the blueprint the eventual build runs on.

How do you roll out automation without breaking your order flow?

A safe rollout is sequenced, parallel-run, and measured — one lane at a time, with coordinators reviewing everything the system produces until the numbers earn trust. The seven-step sequence, and the same pattern we documented in a neighboring vertical in our mortgage workflow automation guide:

1. Map the real order-to-invoice path. Not the process document — the actual route an order travels, including the portal logins, the spreadsheet steps, and the person everyone emails when something is stuck.
2. Pick one lane. One. Usually intake, photo QC, or chargeback defense — whichever currently costs the most hours or the most margin.
3. Blueprint against your real systems and portals. Name the platform, the client portals, the fields, the handoffs, and the human decision points before anything is built.
4. Build on what you run. API, export, or portal — the layer sits on top of your existing platform and your clients’ systems. No migration, no switching.
5. Parallel-run with coordinator review. The system drafts and flags; your team reviews every output for a defined period. Trust is earned in the review queue.
6. Measure against the baseline. Turnaround time, touches per order, photo rejection rate, chargeback recovery — against the numbers you recorded in step 1.
7. Expand lane by lane. Only after a lane holds its numbers does the next one begin. Companies that automate everything at once usually un-automate everything at once.

What does it cost, and how should you measure ROI?

Cost follows scope — how many systems and portals the layer must read and write, how much of the work requires document and image understanding, and how much review tooling your coordinators need — and honest ROI is measured against a baseline you record before anything is built. Be skeptical of any savings figure that arrives without its method. This market quotes percentages freely, and most of them are marketing.

What actually drives cost, roughly in order: the number of distinct client systems involved, because each portal is its own problem; whether the work requires reading unstructured material like photos and scanned documents versus structured data; how much review tooling and audit logging the compliance environment demands; and whether the build extends to front-of-house channels like phones and dispatch. Worth pricing alongside it: the platform upgrade you may not have priced. If a rules engine and an API are one tier away, that quote belongs in the same comparison as any build.

What drives return is frequency. An intake automation that runs several hundred times a week compounds. A clever one-off does not. And this vertical is unusually well-suited to honest measurement, because two of its most painful numbers are already tracked and unambiguous: your photo rejection rate and your chargeback recovery rate. Most industries have to invent a metric to justify an automation project. You already have two, and your clients are keeping score on both.

The stewardship frame we hold ourselves to: an automation should name the hours it intends to return and the number it intends to move before it is built, and be judged against that intention afterward. If a builder cannot tell you what they expect a lane to change, the lane is not ready to build.