CRM for expedition companies

An expedition company (also called a freight forwarder, forwarding agent or 'casa de expeditii' in Romanian) is a service business that arranges cargo transport on behalf of clients. The expeditor does not own trucks, ships or planes — they coordinate between shippers (clients who have cargo) and carriers (transporters who have capacity).

This creates a unique business model: the expedition company is simultaneously a sales organisation (winning client business), a procurement organisation (sourcing carrier capacity at competitive rates) and an operations organisation (managing the physical movement of goods from origin to destination).

A CRM for expedition companies must support all three roles. A generic CRM only supports the first one.

The scale matters too. A mid-sized European expedition company might handle 200-400 shipments per month across 10-15 trade lanes, working with 50+ carriers and 100+ active clients. Each shipment generates an offer, a contract, carrier coordination, document exchange and invoicing. That is thousands of data points per month flowing between clients, carriers and internal teams — far too many for tools designed around a simple 'lead to close' pipeline.

We have worked with dozens of expedition companies that tried generic CRMs before switching. The failure pattern is consistent:

Salesforce / HubSpot / Pipedrive all use the same fundamental data model: Contact → Company → Deal → Activity. This works perfectly for software sales, recruitment, real estate — any business where the 'deal' is a negotiation that ends with a signed contract and a payment.

In expedition, the 'deal' does not end when the contract is signed. That is where it begins. After the contract, there is carrier assignment, cargo loading, customs clearance, in-transit monitoring, delivery confirmation, document collection (CMR, invoice, POD), payment reconciliation and trip closure. A generic CRM has no concept of any of this.

Specific gaps we see:

No transport mode awareness — generic CRMs have no field for 'road', 'sea', 'air', 'rail' or 'multimodal'. You end up creating custom fields that nobody maintains consistently.

No carrier registry — Salesforce can track 'vendors' but not with truck type, operating zone, capacity, ADR certification or blacklist status. These are core operational fields for expedition companies.

No per-shipment margin — generic CRM 'deal value' is the sell price. Expedition margin is sell minus buy, adjusted for FX and surcharges. There is no native way to model this.

No document lifecycle — CMR, invoice, POD and delivery note belong to a specific contract, not to a 'deal'. Generic CRMs cannot model document completeness per shipment.

No multimodal quoting — creating an offer with road + sea + air legs, each with its own carrier and currency, is impossible in a generic CRM without heavy customisation.

No operational phase — the biggest gap of all. In Salesforce or HubSpot, a deal is 'Closed Won' and the pipeline ends. In expedition, 'Closed Won' means the client accepted the offer — now the actual work begins: booking the carrier, tracking the cargo, collecting documents, confirming delivery, reconciling payments. A generic CRM has no concept of this post-sale operational lifecycle that is the core of a forwarder's daily work.

A freight-native CRM built for expedition companies understands the forwarding data model from the ground up:

The central object is the 'offer' (or 'cotatie'), not the 'deal'. An offer has transport mode(s), origin, destination, cargo description, Incoterms, pricing per leg, partner quotes, margin calculation and a lifecycle that flows into a contract.

Clients and partners are separate entities. A client sends you cargo. A partner (another forwarder or carrier) moves it. The CRM tracks both with different field sets — a client has billing terms and volume history, a partner has truck types, operating zones and performance metrics.

Carriers are a first-class entity with fields specific to transportation: vehicle fleet (FTL, LTL, Frigo, Container, Tanker, ADR), geographic coverage, driver contacts, insurance status, blacklist flag. The carrier network module makes this registry searchable and shared across the team.

Contracts are generated from accepted offers — not created manually. When a client accepts your quote, the system drafts both a client contract and a transporter contract from templates, populating variables (route, pricing, parties, references) automatically.

Documents are attached to contracts, not to folders. CMR, invoice, delivery note and POD each have a specific place in the contract record. The system knows when the document set is complete.

Shipment monitoring is built in — milestone statuses from cargo loaded to trip closed, driver and truck plate tracking, estimated vs actual delivery dates, automatic client notifications.

Role-based access controls are designed for forwarding teams — a sales rep sees their clients and offers, a pricing manager sees margin and carrier rates across all deals, an operations coordinator sees shipment statuses and documents, and management sees aggregate analytics and profitability reports. This is not a flat permission model like most generic CRMs — it reflects the way expedition companies actually organise work across departments.

Side by side:

Generic CRM: Contact → Company → Deal (value, stage, probability) → Activity (email, call, meeting)

Expedition CRM: Client → Offer (mode, origin, destination, cargo, pricing per leg, margin) → Partner Quotes (accept/reject per carrier) → Contract (client + transporter, documents, milestones) → Shipment Monitoring (status, driver, truck, ETA) → Invoice & Payment (per contract, per party)

Notice the differences: (1) offers have transport-specific structure, not just a dollar value, (2) carrier quoting is a first-class workflow step, not an afterthought, (3) contracts are linked objects generated from offers, not standalone documents, (4) shipment monitoring continues after the 'deal' is 'won', and (5) invoicing is per contract, per party, with FX adjustment.

This is not something you can retrofit onto a generic CRM with custom objects and Zapier integrations. The data model needs to be native.

There is a practical test you can run: take your last 10 completed shipments and try to model them in any generic CRM. Map out exactly which fields you would need, which relationships between objects, which automations. You will quickly find that the number of custom objects, custom fields and integration workflows exceeds what is practical — and every customisation becomes a maintenance burden that breaks on platform updates. A native data model means these relationships are built-in, maintained by the vendor and optimised for the workflow you actually run every day.

A 40-person freight forwarder in Romania used HubSpot for 18 months before switching to a freight-native CRM. Their experience:

They spent 3 months and EUR 8,000 on a HubSpot consultant to set up custom objects for 'shipments', 'carriers' and 'routes'. The result worked for basic tracking but could not calculate per-shipment margin because HubSpot's deal object does not support multi-currency buy/sell rate pairs.

Their sales team created offers in Excel (because HubSpot could not handle multimodal pricing), then manually logged the deal in HubSpot for pipeline tracking. This meant double data entry on every offer and no link between the pricing and the CRM record.

When a client accepted an offer, the operations team created the contract in Word, separately from HubSpot. Documents (CMR, invoice) were uploaded to SharePoint, not linked to the HubSpot deal. Shipment tracking was done in a separate Google Sheet.

The result: three systems (HubSpot, Excel, Google Sheets), no single source of truth, and management could not see profit per shipment without asking the finance team to run a manual reconciliation.

After switching to a freight-native CRM, the same workflow — from offer to contract to tracking to payment — ran in one system. The contrast mirrors what we describe in Excel vs CRM for freight forwarders. Offer creation dropped from 15 minutes to 3 minutes. Contracts generated automatically. Documents lived on the deal. Margin was visible in real time.

The test is simple: bring your actual workflow.

1. Create a multimodal offer with two transport legs, two different carriers, two currencies.
2. Fan the offer out to three carriers for competitive pricing.
3. Accept the best carrier quote and send the final offer to the client.
4. Generate both a client contract and a transporter contract from the accepted offer.
5. Upload a CMR and an invoice against the contract.
6. Check the margin on the deal — is it correct, considering both currencies?

If the CRM cannot do this in the demo, it cannot do it in production. And no amount of 'customisation' will make a generic CRM do this as well as a platform built for it from day one.

Additionally, evaluate the onboarding experience. How quickly can a new team member — a sales rep who just joined your company — start creating offers? If the system requires a week of training before someone can do basic work, the adoption cost is too high. The best expedition CRMs are intuitive enough that a freight professional can create their first offer within an hour of logging in, because the interface speaks the language of forwarding: legs, modes, carriers, margins — not generic 'deals', 'stages' and 'pipelines'. We cover this in depth in CRM for expedition companies.

Finally, ask about ongoing support. Freight forwarding has peak seasons, urgent shipments and time-sensitive operations. If the vendor offers email-only support with a 48-hour response time, that will not work when your system has an issue at 7am on a Monday morning and 15 carriers are waiting for contract confirmations. Look for vendors who offer responsive support channels matched to the urgency of your operations. Centralising communication is equally critical — see single point of contact in logistics.