Software for ship chandlers who live in their inbox.

A purchase order, start to finish

Most email automation for ship chandlers gets described in the abstract — extraction, classification, workflow. It’s easier to see how it actually works by walking one purchase order through the system, because that’s the unit of work a chandlery deals with all day.

A PO arrives as an email attachment from an agent — a PDF, sometimes a scanned image, sometimes an Excel sheet forwarded from the vessel. The mailbox is one you already use; nothing has to be re-pointed and no MX record changes. BridgeMail reads the message and the attachment together.

First, the message is classified. Is it a purchase order, an RFQ, a quote request, an invoice, or general correspondence? That classification decides what happens next — a PO gets routed differently than a payment query.

Once it’s classified as a PO, the line items get extracted — item codes, descriptions, quantities, units. Alongside the line items, the vessel name, the delivery port, and the requested delivery date get pulled out of the same document, whether they sit in a header block, a table, or scattered through free text.

The extracted order gets queued against the vessel and port it belongs to, so it sits next to any other open business for that ship rather than as an isolated email. From there, the team acts on it — checking stock, pricing the order, confirming delivery — starting from structured data instead of a PDF someone has to re-read every time it comes up.

How chandlers process purchase orders faster

The time cost in a chandlery isn’t usually the decision-making — it’s the re-typing. Someone opens the PDF, reads it, and keys the same information into a spreadsheet or an ERP screen so the rest of the team can work from it. That step is what BridgeMail removes. The order is already structured by the time a buyer or a stores clerk looks at it, so the first useful action on a PO happens minutes after it lands instead of whenever someone gets to the inbox.

For a chandler running dozens of open vessel calls at once, that difference compounds — fewer POs sit unread overnight, and fewer get missed because they arrived at the bottom of a long thread.

IMPA catalog extraction

Ship stores orders are usually written against IMPA (or ISSA) codes, but agents don’t always write them consistently — a code, a partial description, or just a product name copied from a previous order. Extraction is built to read the line item as it actually appears and match it against known product references, rather than requiring the sender to format the PO a particular way. Where an item is ambiguous, it’s flagged rather than guessed silently, so the team reviews it instead of discovering the error at delivery.

Gmail and Outlook without migration

This is email automation for ship chandlers, not a replacement for email. BridgeMail connects to Gmail or Outlook mailboxes you already operate — the ones your agents already have your address for. There is no migration project, no re-training everyone on a new inbox, and no risk of missed mail during a cutover. The chandlery keeps working exactly where it already works; BridgeMail reads alongside it and turns the attachments into usable data.

That matters for a business where every agent, master, and port contact already has a working email address on file. Asking the market to switch communication channels is a much bigger ask than adding a layer that reads what’s already arriving.

Built by a chandler, for chandlers

BridgeMail runs in production at A2Z Ship Stores, a working chandler in India — 149,000 documents parsed, 5,100 contacts auto-built, 219 vessels tracked, on the same inbox pattern described above. See the full A2Z case study.