Skip to content

How it works

A request goes in. Evidence comes out.

Every module rides the same five-stage pipeline. What changes per module is only the carrier handlers in the middle — which is why adding a carrier never touches the rest.

The pipeline

Ask. Orchestrate. Collect. Record. Notify.

How a request flows through NeoA TMS or a dashboard operator sends a request. Neo’s orchestrator groups it by carrier and drives portal logins through a warm browser pool and HTTP clients. Every run is recorded as request, execution and response, then a change-gated notification is sent.Your TMSper-client API keyDashboardsession · owner-scopedNeoOrchestratorgrouping · run concurrentlySmart browserCAPTCHA · sessions · backoffAudit trailrequest → execution → responsePortalsrails · SSLs · pools · MotiveNotificationschange-gated email + CSV
  1. 01

    Ask

    Your TMS calls an authenticated route, or an operator fills a form. Instant requests run inline; scheduled ones register a Central-Time cron and are edited, paused or retraced later.

  2. 02

    Orchestrate

    Items are grouped by carrier and run concurrently through a handler registry. A carrier that is not wired returns a well-formed pending row instead of failing the batch.

  3. 03

    Collect

    A warm, self-healing pool of logged-in browsers and direct HTTP clients do the portal work — CAPTCHAs solved, sessions persisted, logins backed off when a portal is unhappy.

  4. 04

    Record

    Every run is written as request → execution → response with a portal capture as evidence, then normalized so a date means the same thing across every carrier.

  5. 05

    Notify

    A diff decides whether anything moved. Watchlists email only on change or as one daily digest, and ring the in-app bell; billing letters and release requests go out under your company identity with a Message-ID kept.

Design principles

The decisions that make it dependable.

Neo was built by running it against real portals for real loads. These are the rules that survived.

The database is the source of truth for schedules

Queue state is derived and re-registered on every boot, so the job store can be flushed without losing a single watchlist.

A warm, self-healing browser pool

Logged-in portal sessions stay alive per profile with idle self-close and a global concurrency cap, so a repeated check skips the login dance and a stuck browser is replaced, not babysat.

CAPTCHA solving is built in

Cloudflare Turnstile, reCAPTCHA and image challenges are solved in the flow — nobody on your team is asked to click on bicycles.

AI only where it earns its keep

When a carrier sends a return-location table as an embedded image, a vision model reads it. When a spreadsheet's headers are unfamiliar, a model maps them. Everything else is deterministic.

Notifications are change-gated

A per-run diff decides whether a report is worth sending, so a scheduled watchlist emails only when something actually moved — or once a day as a digest.

Registries everywhere

Carriers, notification channels and dashboard modules plug in through one-line registry entries. Adding a carrier changes no pipeline code.

Logins back off when a portal is unhappy

A rejected credential puts that portal on a hold that lengthens on repeat, a rate limit gets a short flat hold, and a passing probe or a saved credential lifts it — so credential rot never hammers a portal.

Dates mean one thing

ETA and last-free-day formatting happens at one choke point per module, so a BNSF date and a UP date land in your TMS in the same shape.

Get started

Give your dispatchers their day back.

A thirty-minute walkthrough on your own Chicago lanes and carriers. We will show a live trace on one of your ramps, a scheduled watchlist and the dashboard your team would open every morning.