Looking for work? Go to Gigson for developers →
Menu

We automated a Lagos loss adjuster's claims process, and found where its claims really wait

Between July and October 2026, we automated the claims process of a Lagos loss adjuster with 19 workflows. Appointments, briefs, final reports and client acceptances now reach the record from email and the ticket queue without anyone typing them in. Every document reminder is logged within two days of being sent, and manual intervention is down to about once a month. In the process we found the real bottleneck: claims wait on documents, not on reports. It is now measured, and fixing it is the next build.

Industry
Insurance
Service
Forward deployed engineers
Team
Two people
Duration
July to October 2026

Results

19
workflows around one claims process
4
milestones recorded without anyone typing
2days
to log nearly every document reminder
27%
of goods-in-transit claims documented within 45 days: the bottleneck we found

The client and the problem

The firm adjusts insurance losses for Nigerian underwriters: about 100 new claims a quarter, across fire, special peril, goods in transit, marine, burglary and a dozen other loss types.

Each claim passes through 16 stages, from job received to report accepted by the client. Stages and documents were recorded by hand in a shared workbook. Reminders to insureds and brokers were logged by hand until March 2026, and then not at all for five months.

The cost was not only the hours. Managers could not see where a claim was without asking, and underwriters could not see it at all. A slow or silent claim put the firm's main relationships at risk.

Discovery

We mapped one claim end to end before building anything, and the map moved the target. The plan had been an AI report Template Creator. The stage dates showed that reports were not where claims waited.

  • Claims wait on documents. Of 51 goods-in-transit claims appointed between 1 January and 22 August 2026, 14 (27%) were fully documented within 45 days. Another 19 took longer, and 18 were still not documented in mid-November.
  • The report is the short part. Once a goods-in-transit claim was fully documented, the final report followed in a median of 17 days (30 claims).
  • The pattern holds across loss types, less sharply. For all other claims in the same period, 70 of 178 (39%) were documented within 45 days.

So the first job was not to write reports faster. It was to make every stage, document and reminder visible without anyone typing it in, so the documentation problem could be measured and then worked on.

Integration

The pipeline was built in n8n around the tools the team already used. The language model that reads incoming email runs locally.

  • Appointment email: the trigger. A new instruction from an underwriter opens the claim.
  • Queue System: each appointment becomes a ticket, and the workbook rows cite the ticket number.
  • Claims workbook: stays the record. The workflows write to it.
  • Sent email: the reminder workflow reads the reminders staff send and logs each one against its claim.
  • Google Chat: where the team already talks, and where the pipeline reports.

Where the data lives: mail, the workbook and chat are Google services, tickets are in a project management system and n8n runs on a hosted server. Only the model runs locally.

Build

We built five things, as 19 workflows.

  1. Milestone recording. Four of the 16 stages are written by the workflow from email and the ticket queue: appointment, brief sent, final report issued and report accepted by the client.
  2. A reminder log that keeps itself. Since 15 August a workflow reads sent email and logs each reminder against its claim.
  3. A data clerk bot in Google Chat. It posts alerts when something fails, a daily progress report, and since 29 August an alert for claims that have gone quiet on documents.
  4. A loss-type review queue. The workflow proposes a loss type for each new claim and a person confirms it.
  5. A claims database the team can question. The workbook is published as a read-only database with one definition for each measure, so a person or an AI agent gets the same answer to the same question. Every figure in this case study came from it.

Launch

The pipeline went live in stages, not on one day. By September nearly every reminder was logged within two days of being sent. It has run on every new claim since: more than 150 claims so far.

Handover

The firm's own team runs it. They read the daily report, act on the Wednesday summary and deal with the exceptions the bot raises. Nobody from the build team logs stages or compiles the reminder list.

Results

We automated the claims process: the record now keeps itself, and manual intervention is down to about once a month. In the process we found where claims really wait. Claims are not faster yet, and that is the next build.

Four milestones, no typing. Appointments, briefs, final reports and client acceptances reach the record straight from email and the ticket queue. Manual intervention is down to about once a month.

Every reminder on record. For five months of 2026, not one reminder was logged. Since 15 August every one is, nearly all within two days. Logged reminders now run at 84 a month, against 44 in the last hand-logged period. Part of that rise is better recording.

And in the process, the real bottleneck. Claims wait on documents, not on reports. Only 14 of 51 goods-in-transit claims were fully documented within 45 days. Once documented, the report followed in a median of 17 days. The firm now knows what to build next: an agent that chases the documents.

Every number here comes from the firm's live claims database.