Never write the adjuster response yourself
First chore: the argument email. The example in the video is an adjuster trying to deny overhead and profit. Instead of drafting the rebuttal from scratch, you boil what you are trying to say into three sentences, prompt the model to explain why the denial does not hold, and send it.
Sometimes the adjuster listens, sometimes not. The point is that you did not spend the hour either way. The response is the same fight you were going to have, minus the writing time.
The response is the same fight you were going to have, minus the writing time.
Analyze the estimate instead of reading it line by line
Second: estimate review. Anyone who has gone through a 700-line-item estimate checking off the electrical and separating trades by hand knows the pain. The video's workflow throws the estimate into the same chat and asks for the breakdown and insights directly.
The separation that used to be an afternoon of highlighting becomes a prompt. You still read the answer with an estimator's eye, but you stop doing the sorting a machine does instantly.
Generate the work schedule and move on
Third, one for the TPA crowd and anyone whose client asks for a timeline: the work schedule, part of the TPA admin burden where margin dies. Two weeks paint, two weeks drywall, laid out by hand, every job. The video's approach is to hand the model the estimate, tell it to be generous with the days, and fire the schedule off to the TPA or the policyholder.
Done, and you do not have to look at it again. It is the clearest example of the pattern across all three chores: structured documents produced from information you already have.
The early glimpse of something bigger
The video closes with XactChat, an early model built from every Xactimate estimate its creator had written, the seed of the line item search that followed. It answers the simple question, like the line item for carpet, and the harder ones, like the related codes or the common line items in a bathroom remodel with specific parameters.
The stated goal was to help estimators avoid tunnel vision and help novices learn to write good scopes. That thread runs straight into what Axiom is now: suggestions grounded in real estimates, reviewed by your estimator before anything becomes an ESX.
