See it run

Two Prices, One Margin.

A freight brokerage does not own a truck and does not own the freight. It sells one thing: the gap between what a shipper will pay to move a load and what a carrier will accept to move it.

Logistics5 min watchWalkthrough

In this video.

A freight brokerage sells the gap between what a shipper pays and what a carrier accepts. A deal with one amount field can record either price but never the margin, so the real business lives in a spreadsheet. Model the deal with both prices and both parties and the margin becomes a field the system computes.

What this covers.

  • A deal with one amount field cannot hold a margin
  • Two prices and two parties on the deal, with the carrier as a record the system knows
  • The load is visible from quote to pay-out in one place
Read the full video transcript.

A freight brokerage does not own a truck and does not own the freight. It sells one thing: the gap between what a shipper will pay to move a load and what a carrier will accept to move it. Every load has two prices and one margin, and the margin is the business. Most sales systems were built for companies that sell a product for a price. They give a deal one amount field. A brokerage can type the shipper's price in it, or the carrier's, but never both, so the margin lives in a spreadsheet beside the system and the system records a business that is not quite the one being run.

This video is about the one decision that fixes that. Everything on screen is a mock demo of Zoho CRM with sample data. Six minutes, one deal record. Here is a load as the default deal record sees it. Account: the shipper, Lakeshore Foods. Deal name: Chicago to Dallas, Friday. Amount: two thousand four hundred dollars. Stage: booked. Which price is that? It is the shipper's price, because the shipper is the customer and the amount is what the customer pays. The carrier, the person who will actually move the load, is not on the record at all.

Their price is in an email. The margin is in the broker's head until Friday, when it is in a spreadsheet. When the owner asks what the margin was this month, the answer comes from the spreadsheet, and the spreadsheet disagrees with the system by a few loads, every month, because they were never the same list. It is worth saying why this happens. The default deal record is right for a company that sells a product for a price, and the brokerage's first administrator set it up in an afternoon from the defaults.

Nobody chose the one-amount model. It was simply there, and the business bent around it. The decision is to make the deal record describe the business. Four changes. A sell rate field, what the shipper pays. A buy rate field, what the carrier accepts. A margin field the system calculates as the difference, so nobody types it. And a carrier field that points at a real record, a carrier company with its own contacts, insurance expiry and history, the way the shipper already does. The standard Amount field stays and holds the sell rate, so every report the system already has keeps working.

Expected Revenue, which the system calculates from Amount and the stage, keeps working too. That is the whole model. It takes an afternoon to add. What it changes is that the margin is now a number the system knows on every load, from the first quote. The carrier change is the one brokerages skip, and it is the one that pays. If the carrier is a record, the system can hold what the brokerage needs to know before it tenders a load: the insurance expiry, the lanes they run, the loads they have moved for you, and whether the last three were on time.

On this mock carrier record, Ridgeline Transport has an insurance expiry in eleven days, and the record shows it in red. The broker sees that on the deal before the load is tendered, not from the claims department after. The shipper has always been a record. Giving the carrier the same standing is what makes the deal two-sided in the system, not just in the margin field. Now the report the owner actually wants. Loads this month by margin: the sell rate, the buy rate, the margin in dollars and as a percentage, grouped by lane and by broker.

It is a standard report on the deal record, because the margin is a field. On this mock month the Chicago to Dallas lane runs at a nineteen percent margin and the Atlanta to Miami lane at seven, and one broker is consistently buying high. None of that was visible when the margin lived in a spreadsheet, because the spreadsheet had one tab and no lanes. The report is the reason to do this. The fields are an afternoon; the report is a different conversation every Monday. One more column the report gets for free: margin by shipper.

The customers who look largest by revenue are not always the ones who pay the margin, and the first time an owner sees the two lists side by side, the conversation about which accounts deserve the best brokers changes. One more thing the two-sided deal makes possible. The load has a life after it is booked: picked up, delivered, proof of delivery received, shipper invoiced, carrier paid. Each of those is a stage, and because the carrier and both prices are on the record, each stage can hand the right number to the right system.

The shipper invoice in Zoho Books is built from the sell rate. The carrier bill is built from the buy rate. The margin the owner saw at quote time is the margin the books show at pay-out, because they were always the same two fields. That is the version of this business where the system and the spreadsheet are the same list, and we have a separate video on the warehouse partner's side of the same load. Two prices, one margin, one record. If your brokerage keeps its margin in a spreadsheet beside the sales system, the system is describing a business you are not in, and the fix is a modelling decision, not a new system.

We are CodeStringers, a Zoho authorised consulting partner. The link below is a no-risk discovery: we look at how your loads are recorded today and show you where the two sides went missing.

Integrated business solutions

One partner. Better outcomes.

We design, build, integrate and operate AI-driven, platform-agnostic integrated business solutions for operationally complex companies. Start with a conversation; we will tell you if we are a fit.