About Shyftbase
Shyftbase is a logistics software company, founded in 2019, that runs land-based freight on one system: order intake, mid-mile and last-mile planning, route optimization, warehouse management, and the automated billing and carrier settlement that follow. Millions of shipments a year run through the platform for retailers, distributors and their carriers.
Shyftbase is a logistics software company, founded in 2019. It builds one system for land-based freight: the order that arrives, the facility and the vehicle that move it, the proof that it landed, and the invoice and the payout that follow. Millions of shipments a year run through it.
This page covers what the company does, who it does it for, how a deployment goes, and what is not published about it yet. There is no leadership grid on it: the company is described here by what it runs and where it stops.
The problem the platform exists to solve
Freight operations rarely come apart at the driving. They come apart at the seams between systems: an order taken in one place, planned in a second, executed on a third, rated in a spreadsheet nobody upstream can see. Every seam is a re-keying, and every re-keying is a chance for one shipment to acquire a second identity that no longer reconciles to the first.
The cost surfaces last, and it lands on finance. A delivery completed on Tuesday is invoiced whenever somebody gets to it. A carrier is paid from a statement assembled by hand. A customer disputes a charge, and the answer turns on whether a coordinator remembers a second attempt. None of it is visible in a demonstration of any single application, because the failure is in the joins rather than in the parts.
Shyftbase automates billables and payables for land-based freight, and that is the company's centre of gravity rather than one feature among several. Automating a payout is only possible when the event that earns it — a completed service, with a time, a place and a scan behind it — already sits on the same record the rate table reads. Which is why the planning, the execution and the proof have to be in the system too: not because one platform is tidier than four, but because the invoice is unbuildable without them.
What the platform does, order to settlement
One order carried through to settlement is the whole of the product. Orders arrive five ways — an EDI document, an API call, a bulk file, a person at a keyboard, or a client's own portal — and land on one record. Planning divides by leg: mid-mile between your own facilities, last-mile for the leg with a customer at the end of it, with route optimization sequencing the stops inside either. Warehouse management holds what is on hand. These are taken as modules on a shared data model, not as a suite with everything switched on.
Then the money, which is the half most transport systems leave to somebody else. A completed service rates against that client's rate table and issues as an invoice line. The same completed service becomes a payout to the carrier or installer who performed it, under rules set per provider, per schedule and per contract term.
Traceability is what holds those two halves together, and it is item-level. A product is created and tracked by scanning it, resolved against a unique identifier and a SKU; driver-app scans record where and when. A damage tag attaches to the image it was found on, so a dent visible on the out-scan at the origin dock and absent at the receiving hub belongs to one leg and one party rather than to an argument nobody wins — what the model layer reads and writes back covers how those tags are made. One record then answers a damage claim, a chargeback and an audit without three separate reconstructions: track and trace with the billing consequences attached. It is not a lot, batch or serial genealogy, and no page here claims one.
Who runs freight on it, and what land-based means
Retailers, distributors, and the carriers and installers who move for them. The operations that fit best are the ones where a delivery is heavy, scheduled into a window, and expensive to get wrong twice. Best Buy and Metro Supply Chain are among the brands whose deliveries run on the platform. Those names are published as names, set in type. There are no client logos on this site and there will not be any until written permission for each mark exists. No individual at a customer is named here, for the same reason: naming a person takes that person's consent, and it was not given.
Every one of those movements is land-based. Shyftbase does not sell air freight, ocean freight, port or vessel operations, or customs brokerage, and nothing on this site should be read as claiming any of them. Cross-border overland movement is in scope: a truck from Ohio into Ontario is land-based freight, and a container on a vessel is not. Where the writing here explains what an ocean forwarder or a customs broker does — as the guide to logistics provider types does, with citations — it is describing the industry, not the product.
The boundary above the product is the same shape. This is a coordination layer, not an ERP and not a general ledger: rated, completed transactions are handed to the system that owns the books, and the published connector list names which module inside each one receives what.
What a deployment looks like
Integrations and onboarding take weeks rather than months for most mid-market operations. That is a shape rather than a quoted figure, and the reason is worth stating plainly: the numbers the legacy site published disagreed with each other, and a number the business cannot stand behind is worse than the gap.
What moves the date is the same short list every time. How many systems have to exchange data, and whether a published connector exists for each. How clean the master data is — sites, service points, rate tables, the postal-code zones a planner works against. And how quickly someone on your side can answer a question about how a charge is meant to work. The third is the usual bottleneck: the project is rarely waiting on engineering. It is waiting for a decision about what happens when a second delivery attempt is billable and the rate table has no line for it. That decision belongs to the operator rather than to the vendor.
Enterprise deployments get dedicated support. What that covers in hours, channels, response targets or severity tiers is not published anywhere on this site, which makes it a demonstration question rather than a commitment made here. So is the cost: the questions a quote turns on are published, and the price is not.
The limits of this page
Five things a careful buyer will ask that this site does not answer, listed rather than hidden.
Security and compliance. No certification, audit report, hosting region or retention period is published, so no page here claims one.
Outcome metrics. No module page carries a first-party performance figure, because none exists with a named customer, a baseline and a measurement date behind it. Every module page argues from mechanism instead — the honest position, and a weaker one than a real number.
Price. No price, unit, minimum, implementation fee or contract term is published anywhere, including here.
Integration mechanics. The systems Shyftbase connects to are named, and each named connection names the module inside that system it feeds. Which objects sync, in which direction and at what cadence is not.
Support specifics. Dedicated support for enterprise is the whole of what is published. No response time, severity tier, channel list or coverage region sits behind it.
Each is a business answer rather than a copy problem, recorded as an open question rather than filled with something plausible. When an answer exists it goes on the page it belongs to, with the date it was given.