How posting a job works
What to include when you create a homeowner job, how photos help, and why Proofstead routes one documented request instead of broadcasting it.
- +Start with the problem, location, and current photos instead of jumping straight to a fix.
- +Proofstead routes one documented request instead of opening a public bid pile.
- +Posting a job does not approve labor. Written scope still comes later and must be approved before work starts.
Start with the clearest version of the problem
The homeowner job form works best when you describe what is happening now, where it is happening, and what you have already noticed. Good examples are a breaker that keeps tripping, a water heater that stopped heating, or a furnace making a new noise.
Proofstead uses that initial record to anchor the rest of the job. That means your first description, property details, and photos can later be compared against the written scope, change orders, and final invoice.
- +Describe symptoms, not just the fix you think is required.
- +Upload current photos when you have them.
- +Include access notes, scheduling constraints, and the best contact method.
What posting the job actually creates
Posting creates a homeowner workspace inside Proofstead. That workspace becomes the running record for your job, including status updates, messages, written scope, approvals, completion details, and any future claim activity.
It is also the source Proofstead uses when routing the job to a vetted contractor. The goal is one organized record instead of scattered texts, emailed estimates, and verbal approvals.
Photos do not replace an onsite review, but they can reduce back-and-forth and make the first scope draft more specific.
What posting does not do
Posting a job is not a final quote, not a guarantee of immediate availability, and not permission for labor to begin. The next important step is still written scope review.
If the assigned contractor later discovers that assumptions changed, Proofstead expects that change to be reflected in a written update before billed work changes.
- +Do not treat the initial request as the final scope.
- +Do not approve off-platform changes if you want the record to stay clean.
- +Use the workspace record as the baseline for every later decision.
