Before an inspection can happen, someone has to assign the job.
That sounds simple, and it should be.
We deliberately designed the process so that assigning a survey doesn’t become an administrative exercise in itself.
Start with the property
The first step is to select the property.
BrightChecker uses searchable selection controls, so whether you have a handful of properties or a much larger portfolio, you can search for the one you need.
Then select the survey template.
Again, you can search rather than having to work through a huge list.
Finally, select the surveyor.
If you only have one or two surveyors, that’s easy.
If you have a much larger team, the same searchable approach applies.
Scheduling is optional
You can then add information such as:
- date
- time
- priority
- instructions
- other scheduling information
But you don’t have to fill everything in.
If you simply want to get a job onto someone’s device quickly, you can provide the essential information and move on.
The system can apply sensible defaults to things such as priority and scheduling.
Importantly, these scheduling details are there to help your organisation manage the work.
They don’t automatically become part of the final inspection report.
The calendar view
There is also a calendar view showing what is happening, when and with whom.
You can filter that information by surveyor and adjust scheduling from there.
That becomes particularly useful when reality intervenes.
Someone is ill.
A job moves.
Another surveyor needs to take over.
The system needs to accommodate that without turning it into a complicated administrative process.
Assigned doesn’t mean locked
This distinction is important.
When a survey is assigned, the field user gets a basic “stub” of the job.
They can see the property, the survey, the scheduling information and other essential details.
But the job hasn’t necessarily been committed to that particular device.
That means it can still be reassigned.
If the office changes the assignment before the surveyor downloads the full job, the next time the device synchronises, the job simply disappears from that user’s list.
If another surveyor has been assigned it, it appears on theirs.
The commit point
There is a deliberate point at which this changes.
The surveyor decides:
“I’m going to do this job.”
They download the full survey.
That is the commit point.
At that stage, the system assumes that the surveyor is actively preparing to carry out the inspection.
This prevents a job that is already being worked on from casually being reassigned to someone else.
One survey, one active device
Once the survey is in progress, BrightChecker also protects against another common problem.
If you open the same active survey on another device, the system can tell you that it is already being worked on elsewhere.
You don’t end up with two different devices independently editing the same inspection.
That avoids the nightmare of trying to reconcile two competing versions of the same survey.
Once the survey has been completed and submitted, however, the situation changes.
You can then move into the review and reporting processes on another device.
Simple administration, controlled workflow
The philosophy is straightforward.
Before someone commits to the job, keep it flexible.
Once someone commits to the job, protect the work.
That gives administrators the freedom to manage their workload while preventing active inspections from becoming confused or duplicated.