How to evaluate property management software: a demo scorecard

A property management software demo can look convincing while leaving your hardest question unanswered: will routine rent questions still reach the operations director after the firm switches systems?

Try a disputed rent balance. Then ask what happens when one roommate moves out and the other stays. Those situations reveal the work your team would do after the sales call. You need to see that work, not just its finished dashboard.

Choose property management software by testing complete workflows with realistic exceptions, then checking the contract against what you saw. A feature checklist can narrow the field. It cannot tell you who will spend twenty minutes fixing an ordinary mistake.

This guide gives a professional management company's buying team a way to run that evaluation. The examples are hypothetical. They are meant to become test cases using the firm's operating rules, with personal information removed.

Set the buying question before the first meeting

Start with a decision you can describe in one sentence. For example: “We need a system in which the office can explain a resident's rent balance without asking the bookkeeper to reconstruct it.” That statement identifies a user, a task, and a problem you can observe.

“We want something modern” doesn't give a salesperson enough direction. It also leaves your own staff free to judge different things. The leasing agent may value fewer clicks, while the owner assumes that the same purchase will replace the accounting system.

Write down what the purchase must replace and what it may leave in place. If your accountant will continue using a separate general ledger, name that boundary. If an association requires a voting workflow, make it an explicit requirement rather than assuming a product that manages buildings will cover it.

Keep a short list of hard requirements separate from preferences. A hard requirement is something that prevents you from operating within your actual obligations or business model. A preference makes a task more pleasant. Mixing them produces misleading scores: a beautiful resident home screen should never cancel out an accounting requirement that the product cannot meet.

Before comparing products, identify which team will own each workflow. The leasing department may prepare a charge while resident services answers questions about it. Talvi is property management software, so the evaluation needs to show how those employees share the record and hand work over. Include the people who run your buildings in the buying process. They should be able to explain which tasks the proposed setup handles and which responsibilities stay with the firm's staff or outside providers.

Treat plan names as the beginning of the comparison

Public product pages can help you select vendors, but plan boundaries matter. As reviewed September 13, 2026, AppFolio's pricing page lists a read-only API in Plus and a read/write API in Max. That is a concrete difference for an operator intending to connect another system. It does not establish which plan or vendor is best for your portfolio. AppFolio plan details.

Use that kind of distinction to ask a precise question: “Which quoted plan supports the direction of data transfer we need?” An integration logo does not answer it. You also need to know which records move, how often they move, and how staff find failures.

Apply the same scrutiny to every vendor, including Talvi. Ask whether each demonstrated function is available in the proposed plan and configuration today. If an answer describes a future release, record it separately. You can consider a roadmap when buying, but staff need to know what they can use on the day you switch.

A fair comparison sometimes ends with different products serving different needs. A larger suite may suit a specialized portfolio. A narrower product may fit a team with a simpler operating model. The useful question is whether the boundaries fit your work.

Bring one household through the whole system

Imagine a 64-unit operator evaluating a replacement for several disconnected tools. Use a fictional two-person household renting Unit 204 for $2,400 per month. One person pays $1,400, the other pays $1,000. During the month they submit a repair request and receive a lease document.

Ask the presenter to create the household, show the charge, and demonstrate what each resident sees. Then follow a payment from the resident's action to the manager's view. Have the presenter explain any period during which payment has been submitted but remains unresolved.

Now change the situation. The first payment is still processing when the second resident signs in. Does the displayed balance explain the amount already in flight? Can staff identify which person submitted a payment without treating the shared rent balance as two unrelated debts?

Continue into maintenance. Ask what happens when the request lacks access instructions, and how the resident sees a status change. Open the document from the resident's account. The point is to test whether the same household remains understandable as you cross from one task to another.

Don't let the demonstration skip inconvenient transitions. A jump from a populated dashboard to a completed report may conceal the work your office will perform between them. Ask to see the transition, or record it as untested.

Use a weighted property management software demo scorecard

Give each test an evidence rating. A simple scale works: zero means not demonstrated; one means described verbally; two means shown by the presenter; three means completed by someone from your team using the proposed configuration.

Then give the workflow a weight reflecting your business. In the hypothetical 64-unit company, payment explanation might carry a weight of five because it affects recurring resident calls. Amenity booking might carry a weight of one because only one building has a reservable room.

Multiply the evidence rating by the workflow weight. Here is a filled-in excerpt for the hypothetical evaluation, not a score for Talvi or another vendor:

The maximum here is (3 × 5) + (3 × 1) = 18. Add your other workflows before treating this as the company's scorecard. The calculation does not make the purchase scientific. It makes the reasons for your preference visible.

Keep hard failures outside the total. Suppose a system scores well overall but cannot supply an export your accountant requires. Label that an unresolved requirement. Do not bury it beneath points earned elsewhere.

Keep a separate acceptance note beside the scores. This fictional record illustrates a buying gate that points cannot override:

An unanswered requirement is not automatically a product failure. It is a reason to keep the evaluation open and obtain the evidence before deciding.

Also record the effort involved. “Completed by staff” is more useful when accompanied by “required two support interventions” or “resident explanation still had to be written manually.” Those notes help you estimate training and recurring work without pretending that click counts alone measure quality.

Test permissions with someone who should be refused

Most demos show an administrator who can do everything. Your staff won't all be administrators.

Choose a narrow role, such as a leasing employee assigned to one building. Ask that person to open a second building, change a payment setting, and edit a document outside their responsibility. A refused action is useful evidence when it reflects the access rules you intended.

Next ask for an ordinary task that the employee should be able to complete. An access model can be too restrictive as well as too broad. If everyone needs an administrator to correct a phone number, work will queue behind the wrong person. If everyone becomes an administrator to avoid that queue, the role design has failed operationally.

Talvi has building-scoped permission checks and distinct view and edit levels for management functions. A useful Talvi evaluation should therefore include a limited staff role and a building outside that person's scope. Confirm the actual role setup with the team rather than assuming a role title matches your organization chart.

Ask for an export before you discuss migration

The ability to enter data gets attention during purchasing. The ability to retrieve it deserves equal time.

Request a sample export containing the records your staff actually need. Check whether it includes stable identifiers, dates, status values, and enough context to distinguish two units with the same number in different buildings. Open it yourself. A file that downloads successfully can still require hours of interpretation.

Separate ordinary exports from a full exit. A rent report may be enough for monthly review but insufficient for a future migration. Ask which documents and historical relationships can be retrieved, who performs the extraction, and what access remains after termination.

These are contract questions as much as product questions. Record written answers and make sure they refer to the service you are buying. Avoid assuming that a support agent's willingness to help once creates an ongoing contractual commitment.

Make the final meeting a staff exercise

After the first round, give each shortlisted vendor the same exercise packet. Include the fictional household, your required roles, the report you need, and a short list of exceptions. Ask for enough access or guided time for the people who will use the system to complete the tasks.

Have those employees work independently before discussing their impressions together. Otherwise, the loudest opinion can become the group's memory of the demo. Ask each person where they lost track of the task and what information they needed next.

For the final decision, prepare a one-page record containing the required workflows, demonstrated evidence, remaining gaps, and first-year cost assumptions. Name an owner for each gap. A gap with a practical workaround is different from a gap nobody has agreed to handle.

If Talvi is on your shortlist, request a demo centered on a shared household payment and a restricted staff account. Let a resident-services employee run the exercise. Can they follow the balance and explain the processing payment without escalating to a portfolio manager? That is a useful test of whether the proposed setup would let the firm distribute routine work across its team.