Broker guideKeep carrier reviews clear during a source outage
Separate unavailable evidence from a negative finding.
Updated 2026-09-13 · CarrierTrail product workflow
Record what failed
Identify which source or check was unavailable and the time of the attempt. Preserve the date of the last usable observation. An empty result caused by a failed request is not the same as a completed check returning no matching rows, and neither is an automatic conclusion about a carrier.
Assign a follow-up explicitly
Choose who will retry or obtain the needed information through another established channel. If a decision depends on missing evidence, record that dependency. Do not mark a review complete simply because a notification was acknowledged or a page was refreshed.
Illustrative example
An authority source cannot be reached while the census record is available. Your note can accurately describe the identity match and the unavailable authority check separately. A later successful source update should be reviewed as new evidence, not assumed to validate the earlier decision retroactively.
Outage handoff
Source unavailable: __. Attempt time: __. Last usable source date: __. Decision affected: __. Alternative check: __. Retry owner and trigger: __.
Worked review example
Illustrative scenario. A filing request fails while a broker is preparing a carrier review. Repeating the request several times still fails. The last successful observation is available, but it predates the current question. The failure should become an assigned review task rather than an empty result or an assumed clearance.
A practical review sequence
Record
Capture the failed source, attempt time and last successful publication date. Avoid replacing the existing observation with a blank entry.
Route
Decide who will check the official source or retry later. State when the unresolved result needs another review relative to the team's work.
Recover
After a successful request, inspect the returned records before closing the task. A restored connection and a resolved carrier question are different outcomes.
What to put in the review record
A handoff should include the affected USDOT, failed check, retained evidence date, retry owner and the question that still needs an answer. Do not include credentials or diagnostic secrets.
Before closing this review
Stop treating repeated identical failures as new information. Preserve the failure once, add meaningful follow-up, and keep the distinction between unavailable data and a verified empty response.
How can a team avoid confusing an outage with a carrier problem?
Keep technical availability separate from the carrier's reported information. Record which source failed, when the attempt happened and which previous observation remains available. Avoid changing the carrier's factual fields simply to represent the failure. Then assign the next check through your normal process. A clear outage record helps the next reviewer see whether the team is waiting for data, waiting for an external confirmation or evaluating an actual change in the company record.
Should a recovered request close every open item?
No. Read the returned result and determine whether it answers the original question. Recovery of the data source is a technical event; completion of the review is a separate decision.
Use these steps alongside your organization’s verification process. CarrierTrail presents public records and saves team decisions; it does not certify carriers or insurance coverage.
Read the data methodology → · All broker guides →