Reference · built on requestOperator by FibricFleet, routes & field

Backhaul Match

Finds the empty return leg on tomorrow's routes and proposes pickups or deliveries along it for the planner to accept.

Request accessPricing ↗

About

Backhaul Match is an operator job that runs after tomorrow's routes are planned. It reads each route's last stop and its end place from your route source and treats the leg between them as unused capacity. It then looks for work that lies along that leg: orders awaiting shipment whose address is near the path, pickup tasks nobody has assigned, and inbound shipments with a pickup stop the fleet could collect.

Each candidate is scored on the extra distance, the time window, and whatever capacity the route source records for the truck. The operator proposes an added stop or a move between routes, with those figures, to the planner. The planner accepts or declines. Only an accepted proposal changes a route, and it is written once.

This is a reference listing. It documents what Fibric would read from Backhaul Match and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Tomorrow's routes: Route4Me routes and addresses with sequence numbers, Samsara routes and stops, Onfleet route plans and their tasks, Bringg post-optimization orders and runs
  • Route ends and truck limits: the DispatchTrack Plan routes webhook with each stop's arrival_time, and trucks with end_place, end_work_time, capacity_one, and capacity_two
  • Orders awaiting shipment with a shipping address: BigCommerce orders in Awaiting Shipment or Awaiting Pickup status, WooCommerce orders in processing status
  • Unassigned pickup work already in the route source: Onfleet tasks flagged pickupTask, Tookan pickup tasks (job_type 0) with job_status Unassigned, Bringg open orders with waypoints
  • Inbound shipments and their pickup stops from project44 shipment tracking and FourKites loads, where the origin sits near the return leg
  • Distance and drive time between the last stop, the candidate, and the end place, from Trimble Maps Route Reports when that connector is bound

Proposed actions

  • Target capability: propose inserting a stop into tomorrow's route: a Route4Me address inserted with reoptimize set, a DispatchTrack stop group, or a Samsara route update
  • Target capability: propose an Onfleet task with pickupTask, completeAfter, completeBefore, and quantity, added to the route through Add Tasks to Route Plan
  • Target capability: propose moving a stop from another route onto the return leg through Route4Me move_route_destination.php or a Bringg driver-to-route assignment
  • Target capability: propose a brief to the planner in Slack or Microsoft Teams: empty leg, candidates, added distance, window fit, accept and decline buttons
  • Target capability: propose an order note or status change once the stop is accepted, such as a WooCommerce order note or a BigCommerce status_id

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Fill a DispatchTrack truck's return leg

    The Plan routes webhook gives each route's last stop and the truck's end_place. Orders in BigCommerce Awaiting Shipment status near that path become a proposed stop group, with capacity_one and capacity_two checked against the truck.

    With DispatchTrack, BigCommerce

  • Add an Onfleet pickup on the way back

    Unassigned tasks flagged pickupTask are matched to route plans whose last task ends nearby. The operator proposes adding the task through Add Tasks to Route Plan and sends the planner the added minutes in Slack.

    With Onfleet, Slack

  • Move a Route4Me address onto the emptier route

    Two routes end at the same depot. A late address on one is proposed for the other through move_route_destination.php, with the reoptimized sequence shown to the planner in Microsoft Teams before anything changes.

    With Route4Me, Microsoft Teams

  • Collect an inbound project44 shipment

    A shipment whose pickup stop lies along the return leg is offered as a fleet pickup. The operator proposes a Samsara route stop, and the planner decides whether the fleet or the carrier moves it.

    With project44, Samsara

Requirements

  • A route source that exposes tomorrow's routes with stop order and an end place: Route4Me, DispatchTrack, Onfleet, Samsara, or Bringg
  • At least one source of candidate work: a commerce connector with open orders, a pickup task list, or a shipment visibility connector
  • A rule for what counts as along the way: the added distance or minutes you will accept, and whether the end-of-shift time may move
  • Slack or Microsoft Teams for the planner's decision
  • Optional: Trimble Maps for road distance and drive time; without it the operator uses the route source's own figures or straight-line distance
Authentication
Holds no credentials. Routes, orders, and shipments are read, and stops proposed, through the connectors you bind, each under its own token or key.

Limits

  • It reads routes for the plan date in the route source. A route created after its last read is not seen until the next one
  • Capacity is checked where the route source records it, such as DispatchTrack capacity_one and capacity_two. Elsewhere a return leg counts as empty under your rule
  • It proposes stops on your own vehicles. It does not book carriers, quote freight, or take loads from a marketplace
  • Time windows come from the order or task record. An order with no window is offered with the route's end_work_time as the only bound

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Backhaul Match ↗

Questions and answers

What does the planner accept?
A brief per empty leg: the route, its last stop and end place, each candidate with added distance and minutes, its time window, and the capacity figures the route source records. Accepting one candidate writes that stop. Declining leaves the route as planned.
Which record does it keep?
Per proposal: the routes and candidates read, the rule applied, the figures shown, the planner's answer and time, and the stop or move as written to the route source. Declined candidates stay listed with the reason.
Will it change a route without the planner?
No. Every stop, move, and order note is a proposal until the planner accepts it. Once accepted it is written once. The operator never re-optimizes a route on its own or touches routes with no empty leg.
Ask about Backhaul Match

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy