Promologistics is a Mexican 4PL logistics operator and already runs OCL Cargo in live operations. This case documents the work that is running today: assign, mirror GPS, bind POD, and audit before pay; which roles stop being the bridge between screens; and how we measure with OCL patterns.

with Promologistics
Live ops
assign · GPS mirror · POD/Tower · audit
4 fronts
OCL pattern auditing 100% of a pilot
5-7%
typical measured-lane window (OCL)
6-8 wks

Who Promologistics is and what live operations means

Promologistics is a Mexican 4PL logistics operator. It designs and executes B2B and B2C supply-chain solutions: logistics, full eCommerce, and loyalty programs.

It operates from Mexico (headquartered in Mexico City) with national and international reach. In the kind of operation where the control tower, POD, and Carta Porte matter every week, the OCL partnership delivers finished work on the freight lane.

Operating context: systems with a human bridge

The pain is rarely the absence of a system. In most cases a TMS, portals, GPS, and Excel already exist. The cost sits in the staff who stitch those screens by hand: quote, assign, chase signal, hunt POD, and release payment.

That is fake freight digitization: the record looks complete because someone completed it. If that person is away, the process stops. The full thesis (tabs, seats, and operating order) lives in that article; here we focus on the live operating lane with Promologistics.

Buying usually centers on user licenses. What is missing is finished work: an agent that closes the shipment with a file finance can defend.

What is running today: four work fronts

Without revealing confidential client operations, the live operating lane aligns with the OCL playbook already documented. Four fronts of finished work, not four more modules in the menu:

Fronts in live ops

Before and after on the lane

Four fronts already running with OCL Cargo. Only the work change.

  1. Assignment

    Before

    Offer split across portal, email, chat

    In live ops

    Close with a trail; tower only if acceptance fails

  2. GPS mirror

    Before

    Portals and screenshots by hand

    In live ops

    Mirror account and alert on the trip ID

  3. POD / Tower

    Before

    Evidence in WhatsApp or folders

    In live ops

    POD bound to the same ID

  4. Pre-pay audit

    Before

    Sampling or Excel beside the TMS

    In live ops

    Rate + CFDI + GPS + POD before pay

Same chain in the OCL playbook. Live operations are judged by verifiable close, not by features.

How the day-to-day runs with computer use

OCL does not require replacing the TMS in the initial phase. The pattern is computer use: the agent operates portals and screens on top of or beside the record. The team decides with a file when something does not close automatically.

Freight operations at a loading yard in Mexico: supervisor reviews a TMS tablet beside a trailer
Live lane context: yard, trailer, and TMS in the same work flow.

Lane operations

What runs live and how the day advances

Agent on TMS and portals; people on exceptions.

Live-ops schema

  1. TMS and portals

    Existing record, rates, and carriers

  2. OCL agent

    Assign, mirror GPS, bind POD, pre-pay match

  3. One file per trip

    Same ID for milestones, evidence, fiscal docs

  4. Tower and AP

    Clear exceptions: signal, POD, rate

Operating day

  1. Open

    Assignment queue

    Carrier offer with an acceptance trail

  2. In transit

    GPS mirror

    Alerts on the ID, not loose screenshots

  3. Close

    POD to the tower

    Evidence bound; closed or pending

  4. Finance

    Pre-pay audit

    Rate + CFDI + GPS + POD

Technical detail: computer use in logistics. The deliverable is the closed shipment, not another inbox.

For the technical pillar: computer use in logistics. For the category contrast: traditional TMS vs OCL.

Roles that improve (and how)

A useful case study does not stop at saying “there are agents”. It should show the shipment flow (assign, GPS, POD, pay or serve) and who stops being the bridge at each stage. In the OCL playbook applied to a 4PL logistics operator, the change reads like this:

4PL process

From assignment to pay, without a manual bridge

The trip moves through four stages. In each one, OCL closes routine and your team decides exceptions.

Shipment flow

  1. Assign
  2. GPS
  3. POD
  4. Pay · Serve

  1. Assign

    Traffic

    Before

    Offer in portal or WhatsApp

    With OCL

    Assigns with a trail on the ID

    Your team now

    Steps in when acceptance fails

  2. GPS · POD

    Tower

    Before

    Rebuilds status by hand

    With OCL

    GPS mirror and POD on the ID

    Your team now

    Diagnosed exceptions only

  3. Pay

    AP

    Before

    Sampling; the rest releases blind

    With OCL

    Pre-pay audit at 100%

    Your team now

    Approves, holds, or disputes

  4. Serve

    Customer service

    Before

    Hunts in groups and screenshots

    With OCL

    Milestones ready on the same ID

    Your team now

    Answers; escalates the claim

Value: free tower, traffic, AP, and service from repeatable work. Your team keeps the exception.

The pattern is straightforward: the agent takes verifiable routine; the person decides when the file does not close. That is operating capacity, not another seat per desk.

Proof we can stand behind

The figures we share are OCL patterns measured in pilots, not the client's internal KPIs:

  • Moving from sampling to auditing 100% of the pilot flow, the typical OCL pattern is recovering on the order of 5-7% of freight spend in the audited universe.
  • Typical measured-lane window: 6-8 weeks, without replacing the whole stack in the initial phase.
  • Qualitative signals you can observe without leaking client figures: diagnosed exceptions only, POD bound to the ID, AP with a file before pay.

The proof we aim to sell is the same on any lane: the invoice matches or is held with a cause. If there is no file, there is no defendable automation.

What a pilot looks like for similar operators

If you run a comparable shipper or logistics operator (many carriers, loaded tower, AP on sampling), the recommended path is not migrating the whole stack overnight. It is one measured lane:

Elige un paso para ver el detalle

Detalle del paso · 01

Pick the lane

Step 1

One corridor or customer with volume; not the whole network.
6-8 week playbook · typical 300+ shipments/month.

Step-by-step detail: 6-8 week playbook. If your buying checklist still talks only about modules, also use the checklist to choose a TMS in Mexico.

Key takeaways5 points
  1. Promologistics is a Mexican 4PL logistics operator already running OCL Cargo in day-to-day ops.
  2. Four fronts are live: assignment, GPS mirror, POD/Tower, and pre-pay audit with computer use on portals and TMS.
  3. Tower, traffic, AP, and customer service stop being the bridge between systems; the agent closes the routine and the team decides exceptions.
  4. The proof in this case is a file AP can defend: the invoice clears or is held with cause.
  5. OCL reference patterns: typical 5-7% recovery auditing 100% of a pilot; 6-8 week window on one lane.

Want the same finished-work lane?

In a demo we build the minimum file for one lane: assignment, GPS mirror, POD, and pre-pay audit. Promologistics already runs with OCL in day-to-day ops. We aim to sell finished work, not another login.
Book a demoSee 6-8 week playbook

Related reading

Frequently asked questions