Shared inbox for logistics teams - every load owned
One dispatch@ the whole ops team works together - track-and-trace answered fast, exceptions surfaced first, PODs where you can find them.
The email problem in logistics is volume with consequences. One dispatch@ takes track-and-trace requests, rate confirmations, PODs and exceptions all day - and a single missed message can be a missed pickup. A shared inbox for logistics gives every load-related thread an owner, keeps documents on the conversation, and surfaces the exception before the angry check call.
Most ops teams live in a mailbox that never stops: a shipper asking where a load is, a carrier returning a rate con, a consignee refusing two pallets, a factoring company chasing a POD - all interleaved, all urgent-looking, only some actually urgent. Whoever opens the mailbox first plays human router for everyone else.
The failure mode isn’t dramatic. It’s the exception email that sat fourth in an unread pile for ninety minutes behind three routine status requests.
What logistics teams actually need
Track-and-trace that doesn’t eat the day. “Where’s my load?” is most of the inbound, and every reply is the same shape: status, location, ETA. The work isn’t hard - it’s constant, and it buries everything that matters more.
Exceptions surfaced first, not in arrival order. A rejected delivery, a driver stuck at a closed receiver, detention starting to accrue - these can’t wait behind routine status mail. A plain mailbox sorts by time; an ops team needs sorting by consequence.
PODs and paperwork that stay with the load. Rate cons, lumper receipts, PODs - when documents live in whichever personal inbox received them, invoicing waits and disputes get ugly. The paper trail belongs on the load’s thread.
Clean handoffs between shifts. Freight doesn’t keep office hours. The evening dispatcher picking up dispatch@ needs to see what’s owned, what’s waiting on a carrier and what’s about to blow up - without a verbal download in the parking lot.
Carriers and shippers kept straight. A carrier negotiating detention and a shipper asking for an ETA are different conversations with different stakes; they shouldn’t share one pile.
How inrelay fits
inrelay is a shared inbox for logistics teams that turns dispatch@ into a queue with owners, urgency and - on every plan - a drafted reply waiting for a human to approve. Requirement by requirement:
The AI agent - recurring drafts, triage and routing - runs on every plan, drawing on the monthly AI credits your plan includes, and it only knows what’s in the thread. Truck positions live in your TMS; drafts speed up the writing, your dispatcher stays the authority.
A workflow example, pickup to POD
What one load’s worth of email looks like when a shared inbox for logistics is doing its job. (The load is invented; the pattern isn’t.)

6:10 am - the status ask
A shipper emails dispatch@: “Where’s load 4417?” Triage tags it track-and-trace and routes it to the dispatcher who owns that account. A draft is already waiting; she checks the TMS, adds the position and ETA, and approves. Two minutes, start to sent.
11:40 am - the exception
The consignee refuses two damaged pallets. That email is tagged as an exception and lands at the top of the queue, not fourth under routine mail. The ops lead takes ownership and leaves a note where the team can see it: “carrier disputing, photos requested.”
3:15 pm - the paper
The carrier replies with photos and, later, the signed POD. Both land as attachments on the same thread - not in one dispatcher’s personal inbox.
Next week - the follow-up
The shipper’s claims question arrives and reopens the same conversation: history, notes, photos and POD in one scroll. The evening shift could answer it cold - which is the whole point.
Integrations that matter here
The plain truth: inrelay has no TMS, EDI or load-board integrations today, and this page won’t dress that up. What it has is the channel most freight communication already runs on - email:
- Everything that arrives by email already works. Rate confirmations, POD emails from carriers, tracking notifications from visibility platforms - they all land in the shared email inbox, get triaged and get an owner like any other thread.
- Live chat for shippers who won’t email. The chat widget on your site gives customers a faster lane for quick status questions, landing in the same queue as dispatch@.
- A knowledge base for the repeat questions. Accessorial policies, claims procedures, detention terms - written once on your own domain, linked instead of retyped.
- No native TMS sync - McLeod, Turvo and friends don’t connect directly today, so positions and ETAs still come from your TMS by hand. If a specific integration would change your answer, name it; that’s genuinely how the roadmap gets ordered.
- No EDI, and SMS - how half your drivers communicate - is in development.
Other teams, same shape.
The vertical changes, the mailbox problem doesn’t. See how the same shared inbox fits other kinds of work.
Every solution
The full list of teams inrelay is shaped for, in one place.
All solutions → REAL ESTATEReal estate
Listings, showings and speed-to-lead - a leads@ that answers first.
For real estate → ECOMMERCEEcommerce & DTC
Order questions, returns and DMs in one queue with owners.
For ecommerce → ACCOUNTINGAccounting firms
Client threads with owners, deadlines that surface, one inbox at quarter end.
For accounting →Give every load thread an owner.
Connect dispatch@ in minutes - one flat price, the whole ops floor on it.