Aljex TMS is deeply embedded at mid-market freight brokerages — the load data, carrier contacts, and historical performance records all live there. What Aljex doesn't provide natively is a carrier scoring layer that connects that historical data to the next tendering decision. This guide walks through the practical integration patterns for adding carrier scoring to an Aljex workflow, covering both the data side and the operational side of making the integration work.

What Aljex Exposes for Integration

Aljex offers two primary integration surfaces: its REST API and its database export functionality. For carrier scoring purposes, the most relevant data sources are:

  • Load history exports: Completed load records including carrier assigned, pickup date, delivery date, agreed rate, and actual rate (useful for detecting re-cover premiums)
  • Carrier contact records: Which carrier was contacted for each load, in what sequence, and whether they accepted or declined
  • Lane data: Origin-destination pairs by zip code, city, or region, tagged to load records
  • Check-call logs: If your brokerage uses Aljex's check-call functionality consistently, this data is a leading indicator of carrier responsiveness

The Aljex API is well-documented for load CRUD operations but less comprehensive for reporting-style exports. Most scoring integrations we've seen pull data via scheduled database exports or use Aljex's built-in report scheduler to push CSV files to an intermediary service.

Building the Scoring Dataset

The minimum dataset for a useful carrier scoring model covers three dimensions: acceptance rate, on-time delivery rate, and fallout rate — all segmented by lane. A lane for this purpose can be defined at varying granularity: state-to-state pairs are a reasonable starting point; ZIP-level pairs give more precision but require more historical data to produce statistically reliable scores.

For each carrier-lane combination, you want at least 10–15 completed loads over a rolling 90-day window to produce a score that isn't dominated by outliers. Carrier-lane pairs with fewer loads should be flagged as low-confidence and handled differently than pairs with strong historical samples.

The data transformation from raw Aljex export to a scored carrier-lane matrix typically involves:

  1. Normalize carrier IDs (Aljex carrier records can have duplicates across MC# and DOT#)
  2. Filter to loads where the carrier contact sequence is intact — incomplete records skew acceptance rate calculations
  3. Compute per-carrier, per-lane metrics over rolling windows (90 days is standard; 30 days for high-volume lanes)
  4. Apply a fallout adjustment: carriers who accepted but fell out within 24 hours of pickup should be scored lower than their acceptance rate alone suggests

Surfacing Scores in the Aljex Workflow

Scores are only useful if they're visible at the moment a broker is making a tendering decision. There are three patterns for surfacing scores within Aljex:

Pattern 1: Score field in the carrier record. The simplest integration writes a composite score (0–100) back to a custom carrier field in Aljex. Brokers see the score when they pull up a carrier profile. Downside: the score is carrier-level, not lane-specific, so it doesn't reflect the carrier's performance on this particular O-D pair.

Pattern 2: Enriched carrier search results. A middleware layer intercepts the carrier search query in Aljex, appends lane-level scores to the results, and returns a sorted list. This requires either an Aljex API integration or a browser extension that injects score data into the existing Aljex interface. More complex, but lane-specific scoring is materially more predictive than carrier-level scoring.

Pattern 3: Side-panel recommendation tool. A separate application (browser extension or standalone panel) that receives load details from Aljex via API and returns a ranked carrier shortlist with confidence scores. The broker sees recommendations alongside their standard Aljex workflow without the integration needing to modify Aljex data directly.

Data Refresh Cadence

Carrier performance data changes. A carrier who ran clean on the Chicago-to-Detroit lane for six months can develop quality issues after a fleet expansion or operational change. Scoring models should be refreshed on a daily basis for active carrier-lane pairs, with a rolling window that weights recent loads more heavily than older ones.

A practical approach: nightly Aljex export, next-morning scoring model refresh, scores available by 7 a.m. before peak tendering activity. For brokerages running overnight or early-morning freight, intraday refresh may be necessary.

Fallback Logic for Unscored Carriers

Every integration needs a fallback for carrier-lane pairs with insufficient history. Options include: score the carrier at their overall average (ignoring lane specificity), prompt the broker with a "no lane history" flag and let them decide, or pull DAT or Truckstop posted capacity as a proxy for availability. The last option is most useful when combined with carrier-level average performance as a minimum-confidence score.

Integrating carrier scoring into Aljex is not a one-week project, but it's also not a months-long overhaul. The data is already in your TMS. The primary investment is in the extract-transform pipeline and the UX layer that brings scores to the broker at decision time. For brokerages at median first-tender rates of 65–72%, the operational upside from moving toward 78–82% is measurable within the first 60 days of deployment.