Laycan dates are small pieces of text with large commercial consequences. A useful shipbroker email parser must extract laycan windows, normalize them into searchable data and still keep the original broker email visible so the broker can verify the context before acting.
| Email text | Structured field |
|---|---|
| 22/28 July | Laycan start: 22 July, Laycan end: 28 July |
| end July | Approximate laycan window: late July |
| prompt | Availability flag requiring broker review |
| abt 25 July | Approximate date with low-confidence marker |
LaycanMatch should never hide uncertainty. Low-confidence or ambiguous date extraction must stay visible so the broker can review the source email before contacting anyone.
The broker problem
Laycan dates are often written in inconsistent formats: 22/28 July, end July, prompt, abt 25 July. Brokers need speed, but they also need to know when the date is exact and when it is approximate.
What changes with structured email processing
Structured extraction turns laycan text into searchable fields while still preserving the original source text. That makes filtering faster, but it does not hide uncertainty.
Example workflow
A cargo email says end July while a vessel offer says 26/31 July. LaycanMatch can mark both as searchable date data, compare overlap and still show the source email so the broker can verify the real context before acting.
What LaycanMatch does
LaycanMatch extracts laycan dates, keeps the original laycan text, flags uncertain values with confidence and uses laycan overlap as one of the ranking signals when matching cargo offers and vessel positions.
What still stays under broker control
The broker reviews ambiguous date extraction, decides whether a prompt or approximate date is acceptable and makes the commercial call.