Skip to content

Vehicle Accident & Damage Intake

Example prompt: "When a driver submits the bump-card Google Form, draft the first-notification-of-loss email to our insurer, log the incident to the claims register, and post an alert in #fleet-urgent on Slack with the manager tagged so the third-party capture window does not close."

The Problem

A driver clipping a wing-mirror on a parked van at 11am will not call the office until they finish the run, by which time the insurer's third-party capture team has lost the window to contact the other driver first and the credit-hire firms have already booked them in. The bump-card information is on the cab paperwork, the dashcam clip is sitting on the device, the tacho download covers the moment, the telematics has the speed trace — but pulling it together into an FNOL email by hand takes the manager an hour at the end of a day they did not plan to lose. The case that bites is the one where nobody started the claim until the following morning, and the insurer's premium loading on the next renewal reflects it.

How GloriaMundo Solves It

We build a workflow that fires the moment the driver submits the bump-card form. An integration step reads the form response. A code step looks up the vehicle, the driver, the run, and the policy from the operations sheet. A conditional step branches on the severity self-rating — minor (no injury, drivable) goes to the standard FNOL flow; significant (any third party, any injury) routes additionally to an urgent Slack page to the duty manager. An LLM step composes the FNOL email body with every field the insurer needs in the first 24 hours — policy number, date, time, location, VRN, driver, third-party details, description, photos, injuries, police reference, drivability. An integration step saves it as a Gmail draft to the broker, logs the incident to the Claims Register, and posts the Slack alert. Glass Box preview shows the FNOL draft and the Slack page before either reaches the broker or the manager.

Example Workflow Steps

  1. Trigger (integration): A submission to the driver bump-card Google Form lands.
  2. Step 1 (integration): Read the form fields — driver, VRN, date, time, postcode, what3words, third-party VRN, third-party details, description, injuries (yes/no), police reference if given, photos, drivability self-rating, dashcam_device_id, severity self-rating.
  3. Step 2 (integration + code): Look up the driver record on the Driver Register, the vehicle on the Vehicle Register (policy number, broker contact, insurer name, GIT policy if applicable), and the run on the Run Log for that (VRN, date). Compute incident_id as 'INC-[YYYY]-[6-digit sequence]'.
  4. Step 3 (code, gate): Dedupe on form_response_id against the 'Claims Register' tab. Final state ('Logged' or later) halts; provisional state ('Allocating') resumes; no row writes a provisional row with status 'Allocating' before any subsequent step.
  5. Step 4 (conditional): Branch on severity_self_rating — minor (no injury, drivable) routes to the standard FNOL flow; significant (any injury, any third-party injury, vehicle not drivable, any HGV >3.5t) routes additionally to the urgent path in Step 8.
  6. Step 5 (llm): Compose the FNOL email body — policy number, date and time, postcode and what3words, VRN, driver name, driver licence reference, third-party VRN and details if given, description in the driver's words, injuries, police reference, photo links, drivability, witness details if given, and a request for the broker's claim reference.
  7. Step 6 (integration): Save as a Gmail draft to the broker with photos attached from the form's Drive folder. Persist gmail_draft_link to the provisional Claims Register row.
  8. Step 7 (integration): If the dashcam_device_id is populated, post a one-line note in #fleet-urgent on Slack reminding the manager to pull the 60-second pre/post clip from the dashcam portal before the device's storage rotates over it.
  9. Step 8 (integration): For significant incidents, post a higher-priority page in #fleet-urgent tagging the duty manager with the incident_id, the location, the driver welfare prompt, and a link to the provisional Claims Register row.
  10. Step 9 (integration): Flip the provisional Claims Register row's status from 'Allocating' to 'Logged'. The broker reference number gets written back to the row by the manager (or by a separate listener on the broker's reply email) once the claim is opened.

Integrations Used

  • Google Forms — the driver bump-card form
  • Google Sheets — the Driver Register, Vehicle Register, Run Log, and Claims Register
  • Google Drive — the form's photo upload folder
  • Gmail — the FNOL draft to the broker
  • Slack — the dashcam-pull reminder and the duty-manager page for significant incidents

Who This Is For

Fleet managers and compliance leads at small couriers, last-mile firms, and regional haulage operators who carry their own motor and goods-in-transit policies, where the window between a bump happening and the broker opening a claim is the difference between a managed renewal premium and a year of credit-hire arguments.

Time & Cost Saved

Pulling an FNOL together from a paper bump card, the cab paperwork, the rota, and the dashcam portal typically costs a manager 45 to 60 minutes per incident, and the claim does not get opened until the broker is back at their desk the next morning. This workflow puts the FNOL draft in the manager's inbox within minutes of the driver submitting the form, and the dashcam clip and tacho download are flagged for retrieval before the device rotates over them. The credit-hire window stays in the operator's favour, and the per-claim admin overhead drops from an hour to ten minutes.