Overview
The strongest workflow is not the one that fills every field. It is the one that helps the desk identify usable information, recognise conflicts and decide what needs confirmation before a vessel is proposed for employment.
Key takeaways
- Retain the original message behind every extracted field.
- Distinguish a ship's identity, observed position and commercial opening.
- Route unresolved alternatives and contradictory updates for review.
- Test the exception workflow as carefully as routine extraction.
Define the intended output
Start with a narrow record: vessel identity, proposed opening area, expected availability, source, message timestamp and qualifications. Decide which additional particulars the team actually needs before expanding the field list.
Each field should have a meaning that can be explained to a reviewer. “Position” might refer to a physical observation, the next destination or the location where a vessel is expected to become available. Combining these meanings produces a tidy but misleading list.
The output should therefore preserve field type and status. If the message supplies a forecast, the stored value should remain a forecast. If it offers alternatives, the alternatives should remain visible until an authorised source resolves them.
Identify exceptions before designing automation
Gather representative difficult messages using information the organisation is authorised to process. Include revisions, cancellations, shorthand, multiple vessels in one email and quoted histories containing older opening dates.
Label what a competent reviewer would do. Sometimes the correct result is an extracted value; sometimes it is an unresolved question. A test set that only rewards filled fields encourages the wrong behaviour when the source does not support certainty.
Keep the examples separate from operational records used for live decisions. Fictional or appropriately redacted messages can help develop the process without implying that a demonstration represents current vessel availability.
Use an exception-routing matrix
| Message pattern | Safe structured treatment | Human review question |
|---|---|---|
| Several possible opening areas | Preserve the alternatives | Which area is currently being offered? |
| A date appears only in quoted history | Keep source context; avoid promoting it automatically | Does it still apply to the latest update? |
| Same vessel with conflicting availability | Link a conflict to one reconciled identity | Which message supersedes the other? |
| Cancellation or withdrawal | Flag the existing record for the defined withdrawal workflow | What should stop being offered? |
| Missing year or unclear time basis | Mark the field unresolved | What date interpretation is supported? |
| Instructions unrelated to extraction | Do not execute them | Is any authorised follow-up needed outside the parser? |
The matrix describes desired behaviour, not universal parsing rules. The desk must adapt it to the messages it receives and the actions its system is permitted to take.
A fictional quoted-history failure
Consider an email chain whose earlier message offers a vessel in one area. The newest reply says the ship is no longer available on that basis and asks the recipient to await a revised position. A parser extracts the clear location and date from the older message because those fields are easier to recognise.
The resulting row appears complete but reverses the meaning of the update. The fix is not merely a better date pattern. The workflow must identify quoted history, interpret the latest message's relationship to the earlier offer and avoid presenting withdrawn information as current.
A reviewer should see the source passages and the conflict. The system can propose a status change for review, while the team's defined process controls whether an existing commercial record is withdrawn or amended.
Make the review screen support decisions
Show the original passage beside the extracted field, its uncertainty and any previous conflicting value. Give the reviewer distinct actions: confirm the extraction, correct it, leave it unresolved or request clarification through the authorised communication process.
Do not hide uncertainty behind a colour alone. Explain why the item was flagged. A missing date, contradictory source and uncertain vessel identity are different problems; the reviewer needs enough context to choose the right next step.
Record the correction and its reason. This is useful for diagnosing systematic errors and for understanding why a live record differs from the parser's first output. Avoid replacing the first result without an audit trail.
Measure outcomes that matter to the desk
Accuracy should be assessed at the level of meaningful fields and consequential errors. A system can correctly extract many easy details while repeatedly mishandling the availability condition that determines whether a vessel should be shortlisted.
Review false certainty separately from harmless omissions. Leaving an unclear field open may create a small amount of follow-up work; presenting an unsupported opening as confirmed can create a different commercial problem. The quality assessment should recognise that difference.
Also measure the review burden and the usefulness of explanations. If every item requires reading the full chain again, automation may have shifted work rather than reduced it. Any claimed efficiency result needs an observed baseline and a clearly defined measurement period.
Pilot without bypassing confirmation
Begin with a bounded message set and a defined destination for extracted records. Keep the pilot's outputs separate from actions that propose ships, change fixture status or send instructions, unless those actions have their own authorised controls.
- Define permitted inputs, fields and destinations.
- Label ordinary and exception examples before evaluation.
- Compare outputs with the agreed reference decisions.
- Review consequential errors and unresolved cases.
- Confirm the human approval and correction workflow.
- Expand only after the responsible team accepts the evidence.
Document how to pause the workflow and revert to the established manual process. A pilot should test what happens when the system is uncertain or unavailable, not only how it behaves when an email matches the expected format.
Common mistakes
Avoid equating a complete row with a reliable row. Do not let older quoted content silently override a newer withdrawal. Do not use a model's confidence-like output as proof that the underlying message is true.
Another mistake is giving an extraction service unnecessary authority to send messages or edit unrelated records. Restrict the task to its approved purpose and keep the commercial confirmation process visible.
Where Zeaclub fits
Zeaclub supports agentic, AI-assisted operations with a human in control.
Zeaclub provides a multi-party shared workspace for owners, charterers, brokers and port agents.
Explore Zeaclub
Educational information only; not legal, financial or trading advice. Contract wording and applicable rules control. Verify current requirements and obtain qualified advice before acting.
Frequently asked questions
Should a parser fill every missing field?
No. If the source does not support a value, mark it unresolved. A question with a clear owner is preferable to unsupported certainty.
Can physical position establish commercial availability?
No. Keep observed location and the proposed commercial opening separate, and obtain the confirmation required by the desk's process.
What should happen when two messages conflict?
Reconcile vessel identity, preserve both sources and route the conflict for review. Do not silently select the most convenient field value.
How should success be measured?
Use field-level evidence, consequential error rates, exception handling and reviewer workload. Do not claim commercial savings without an observed and documented basis.