About Sortwyre
Built by a sortation operations supervisor who saw the same throughput gap every peak season and decided to fix it.
Malik Johansson spent three years as a sortation operations supervisor at a Memphis-area regional parcel hub, managing a 6-lane crossbelt sorter that consistently ran 22% below rated throughput on peak days despite no equipment faults. The engineering team had checked the hardware repeatedly. Nothing was broken.
The problem was the control parameters. They had been set at commissioning in 2018 and never touched, even as the facility’s parcel mix had shifted significantly toward larger, irregular e-commerce boxes. The induction spacing and divert timing were still tuned for the 2018 mix. Malik’s job—watching the reject lane and manually calling in rate adjustments—had become the only adaptive feedback loop the sorter had. It was exhausting, and it was inconsistent from shift to shift.
In 2024, he built a monitoring dashboard that gave shift supervisors real-time visibility into induction rate, throughput, and reject counts on the same screen. Within two weeks, supervisors used that visibility to make manual adjustments that recovered 14% of the throughput gap. The facility’s operations director called Malik into her office and asked one question: can it make the adjustments automatically?
That question became Sortwyre. Not a new sorter, not a WMS replacement—a real-time optimization layer that connects to existing sorter PLCs via OPC-UA and continuously adjusts induction and divert parameters within the envelope the MHE vendor allows. The adaptive control loop that the hardware always needed but never had.
Close the gap between rated sorter capacity and actual throughput by making sortation parameters adapt to the parcel mix, not the other way around.
Mid-size fulfillment centers running 15,000–80,000 parcels per shift routinely operate 20–35% below their sorter’s rated capacity. The hardware is capable. The parameters are frozen. Sortwyre exists to fix the mismatch, one facility at a time, without asking operations to rip out equipment that still has years of useful life.
We measure success in parcels per hour recovered — not in dashboard views, not in reports generated. Our founding philosophy is simple: the control system should know what the parcel mix is doing right now, and the parameters should reflect that. Every 90-second optimization cycle is a direct expression of that commitment. No rip-and-replace. No forklift upgrades. Just the throughput the hardware was always rated to deliver.
Sortwyre is an early-revenue seed-stage company. We are working closely with a small number of pilot operators to validate throughput recovery, refine the OPC-UA integration layer, and establish the right baseline methodology for facilities with different sorter configurations.
We are not yet taking on every facility that reaches out. Our current focus is on crossbelt sortation environments running two to eight lanes in the 15,000–80,000 parcel-per-shift range. If that matches your setup, we want to hear from you. If it does not quite fit yet, sign up for updates—we are expanding the supported hardware list throughout 2026.
Sortwyre connects to existing sortation hardware via OPC-UA or Modbus TCP. You keep the sorter, the WMS, and the MHE vendor relationship. We add the adaptive control layer on top.
Not dashboard views, sessions, or “insights generated.” If a facility’s throughput does not increase in measurable, shift-level terms, we have not done our job.
Every parameter adjustment is visible and explained in the dashboard before the system applies it at scale. Supervisors can see the current rate target and the reason behind it at any point during the shift.
We do not run a black-box optimizer. When Sortwyre widens an induction gap, the dashboard tells the operator why—whether it is a scanner read-rate drop, a jam sensor event, or a parcel mix shift. Explainability is not optional.
The belt health early-warning module exists because unplanned downtime costs more than a planned maintenance window. Sortwyre flags degradation signals 2–6 hours before failure events so maintenance can intervene during a break, not during peak throughput.