2026 5 min read

Making laytime claims
easier

Designing claims workflow for dry and chemical vessels

SHINC sign-in screen next to the AI SOF Parser onboarding panel, shown on a laptop, with a cargo vessel at sea behind it

Why was this needed?

Laytime claims bring together time, contracts and events from a vessel’s port stay. For a claims analyst, creating a claim means collecting information from the Charter Party, Statement of Facts, cargo details, port events and applicable exclusions, then turning it into a defensible calculation.

SHINC brings these pieces into one workflow. It digitises laytime calculations, structures Statement of Facts data, connects operational timelines with contractual terms, and keeps the claim history auditable.

Dry parcel

A more conventional claim where one cargo and one charter party define the calculation.

Chemical parcel

Multiple parcels and charterers can share the same port call, while each keeps its own commercial terms.

Incremental claim

A long-running port stay can be claimed in smaller billing periods instead of waiting until the vessel leaves.

The workflow before SHINC

A lot of the work happened outside the claim system. Analysts gathered information from different sources, interpreted the operational timeline, applied contractual rules and built the final claim.

For chemical parcels, the existing model assumed one voyage, one charter party and one laytime calculation. A single vessel call could instead involve several charterers and parcels, requiring the same port and Statement of Facts information to be entered repeatedly.

Incremental claims introduced another challenge: the analyst needed to manage smaller billing periods against one larger expected claim during a long port stay.

Designing a single claim experience

The challenge was not just calculation. The bigger question was what should stay common across claim types and what needed to change.

I approached claim creation as a shared framework rather than three completely separate experiences. The common structure remained familiar: Contract → Operations → Calculation → Claim. The level of complexity changed depending on the claim.

Early exploration / information architecture showing the shared claim structure

01 · Dry parcel claims

The dry parcel flow acts as the foundation. The analyst starts with contract and cargo information, adds the relevant port activity, reviews the calculation and prepares the claim.

The design focus was to keep the standard path predictable. Contractual information is entered once, operational events feed the calculation, and the result remains visible and traceable to the underlying inputs.

Dry parcel — claim creation or calculation screen

02 · Chemical parcel claims

Chemical parcel claims introduced a different challenge. A single port call can involve several charterers, each with different cargo, rates and contract terms. At the same time, they may share the same operational events.

The new model treats the voyage as the shared context, while keeping each charterer’s financial calculation independent.

Chemical parcel — parent claim with multiple charterers

The claim structure became:

Voyage / Parent Claim
Charterer A Charterer B Charterer C

Each charterer keeps its own calculation and send-out, while the owner can still see the overall exposure for the voyage.

Shared operational events also needed a clearer model. Ports are created once, charterers are selected for each port, and activities or exclusions can then be assigned to the appropriate charterers. Allocation defaults to quantity share but can be adjusted at the event level.

This separates operational complexity from commercial complexity. The activity can be shared while each charterer’s contract and financial calculation remain independent.

Activities / exclusions allocation matrix

03 · Incremental claims

What happens when the voyage is not over yet?

Some port stays continue for weeks or even months. Waiting until the vessel leaves port to raise the entire claim is not always practical.

The incremental claim experience lets an analyst create smaller billing-period claims against one Parent Claim. The Parent Claim represents the expected total for the port stay, while each increment captures one period of demurrage.

Parent Claim with incremental claim history
Parent Claim$40,000 estimated total
Increment 01 Increment 02 Increment 03

Keeping these periods connected gives analysts a clear history without turning every period into an unrelated claim. The system also checks for overlapping billing periods and keeps the total of the increments aligned with the Parent Claim.

The live calculation preview was another important part of the experience. As the analyst changes the billing period, port, rate or exclusions, the demurrage result updates before the claim is created.

Incremental claim modal with live calculation preview

What I learned from the different claim types

Keep shared information shared

A port call should not have to be recreated just because another charterer is involved.

Separate operational from commercial complexity

The vessel activity can be shared while each charterer’s contract and financial calculation remain independent.

Make calculations understandable

The analyst needs to see not just the final amount, but the inputs and time contributing to it.

Keep exceptions inside the workflow

Overlap warnings, invalid periods and unusual exclusions are handled while creating the claim rather than discovered later.

Collaboration & refinement

Designing the experience meant aligning the interface with real operational rules. Chemical parcel claims required decisions around charterer relationships, shared events, exclusions, reversible and non-reversible calculations, and how claims should roll up under a parent voyage.

Incremental claims similarly required careful definition of billing periods, parent totals, overlap handling and calculation behaviour before the interface could be simplified.

Annotated design exploration or key iteration

Rather than adding more screens to accommodate every edge case, the goal was to keep the primary workflow straightforward and surface complexity only where it mattered.

Final designs

One framework, different claim scenarios.

The final experience gives analysts a consistent way to create and review claims while supporting the differences between dry parcels, chemical parcels and incremental billing.

Dry parcel — final screen
Chemical parcel — multi-charterer screen
Allocation matrix — shared activity screen
Incremental claim — creation modal
Parent Claim — with claim history

From calculating claims to managing them

The real shift was not simply moving laytime calculations into software. It was giving analysts a clearer structure for working with claims that can be simple, shared or ongoing.

Closing visual — strongest SHINC screen or final product montage

SHINC brings contract details, operational events, calculations and claim history together, while still giving analysts control over the decisions that matter.