Start with the work, not the feature list
Residential surveying software should be judged against the instruction as it actually moves through your practice. A long feature list is less useful than a clear answer to three questions: who owns the next action, what evidence crosses the handoff, and what prevents an incomplete or unreviewed report from being issued?
Map one real instruction from enquiry to delivery before speaking to a supplier. Include the awkward parts: a changed appointment, missing terms, photographs added late, a report returned from QA and a colleague covering another surveyor. That map becomes your test script and stops a polished demonstration from defining your requirements for you.
The 15 questions to ask every supplier
- 1
Which stages of an instruction are genuinely connected?
Look for a clear path from enquiry, quote and terms through inspection, report review and delivery. Ask where information is re-keyed or exported.
- 2
Where is the source of truth for status and ownership?
Every live instruction should have one visible stage, owner and next action. If two screens can disagree, ask which one governs the work.
- 3
Can access follow the way the practice is organised?
Test an administrator, a surveyor and a reviewer. A hidden menu is not a permission boundary, so ask what the server prevents each role from reading or changing.
- 4
What remains under the surveyor's professional control?
Automation should not silently accept findings, condition ratings or final wording. Ask what requires an explicit review and who is recorded as making it.
- 5
How is AI use governed and evidenced?
The current RICS responsible AI standard covers governance, procurement, professional judgement, output assurance and client communication. Ask how the system supports each control without claiming to replace the firm’s own responsibilities.
- 6
Can you trace a statement back to its working context?
Test whether notes, photographs, generated suggestions, edits and approvals remain understandable after the report has been issued.
- 7
What personal and client information is processed?
Ask for the purpose, location, retention period, subprocessors and deletion route. The ICO’s data protection by design guidance expects privacy to be considered throughout a service’s lifecycle, not added after procurement.
- 8
What security evidence can the supplier provide?
Ask about authentication, access control, encryption, backups, incident handling and independent assurance. The NCSC cloud security guidance recommends building confidence in how a provider protects data and understanding the shared responsibility model.
- 9
What happens when connectivity is poor?
Do not accept “offline ready” as a label. List the exact actions that work without a connection, what stays on the device, and how conflicts or failed uploads are shown.
- 10
How are templates and practice wording controlled?
Check who may alter templates, how changes affect live and historical jobs, and whether a practice can test a change before making it available to everyone.
- 11
What is involved in onboarding and data migration?
Separate configuration, training, template work and historical import. Ask who does each task, how long it normally takes and what the practice must prepare.
- 12
Which integrations are live, and which are only planned?
Ask to see the current integration complete a real action. Record the owner, failure behaviour and support boundary for each external service.
- 13
How are failures, support and recovery handled?
Ask how the supplier detects a failed email, incomplete upload or delayed background task, how you are told, and what evidence remains for support to investigate.
- 14
What is the complete cost at your likely usage?
Include active users, storage, AI usage, onboarding, support, payment processing, annual increases and any modules needed for the workflow shown in the demonstration.
- 15
How can you leave?
Confirm export formats, notice periods, access after cancellation and deletion timing. An exit route is part of operational resilience, even when you expect the relationship to last.
Use a simple evidence score
Do not score a promise and a working demonstration equally. Give each question a score from zero to two and retain the evidence that supports it.
| Score | Meaning | Evidence to retain |
|---|---|---|
| 0 | The answer is missing, unclear or depends on an uncommitted future feature. | Record the gap and its operational consequence. |
| 1 | The answer is plausible but supported only by explanation or generic documentation. | Keep the written answer and identify what the trial must prove. |
| 2 | The behaviour is demonstrated against your scenario and the relevant control is documented. | Keep the test result, document link and any agreed configuration. |
A total score is useful for comparison, but a serious zero should remain visible. Weak job access control, an unclear data exit or a false claim about professional review cannot be cancelled out by several convenient minor features.
Run a trial that can change your decision
A meaningful trial uses a representative instruction and has named acceptance checks. Configure a small group, keep the current process available, and include at least one exception rather than testing only the happy path.
- Set up the practice identity, roles, report structure and working phrases.
- Take one real or safely anonymised instruction from enquiry through report review.
- Test a returned draft, a reassigned job and an interrupted upload.
- Export the information you would need if the trial ended.
- Ask each participant what became clearer and what created a new workaround.
Do not use an illustrative time-saving percentage as the acceptance test. Measure the actual steps, handoffs and rework in your own practice. That produces a decision you can explain even if the result is not to buy.
Make the decision on control, fit and evidence
The best choice is not necessarily the system with the most functions. It is the one that makes your important work visible, preserves professional judgement, fits your team’s operating reality and provides enough evidence for you to trust the service.
Keep the completed checklist with the procurement decision. It becomes the starting point for onboarding, the first review after implementation and a more disciplined conversation when the product or your practice changes.
How this guide was prepared
The SurveyOS Editorial Team prepared this guide using current primary sources and evidence from the product workflow. AI assisted with drafting and structure. The factual claims and product statements were checked against the sources and current application behaviour on 4 August 2026. This is general practice guidance, not legal or professional advice.
Primary sources
Put the workflow to the test
See SurveyOS on one real instruction.
Book a demo and compare the workflow with the way your practice works today.
