Eassons’ 98% Touchless Load Entry Started With Recipe Cards

The lead account manager at Eassons had a physical recipe-card holder. One card for each customer. Except these recipes were for moving freight: the temperature to set, the weight conversion to use, the delivery schedule to follow. The holder contained instructions that a shipment document alone could not supply. Before an agent could build a load, it needed to learn what was on those cards. [1]

That is an unusual place to begin an automation story. Usually, the opening scene is a screen: a crowded inbox, a spreadsheet, a person copying numbers from one window to another. The cards move the story one step upstream. They explain why the person has to be there in the first place.

A customer sends a tender. It contains information. But information is only useful if someone knows what it means for that particular account. A weight needs a conversion. A delivery needs the right schedule. A temperature needs context. The employee supplies the missing instructions, often so quickly that the work looks like typing.

The holder made that invisible work visible. Eassons did not simply have a data-entry problem. It had a knowledge-transfer problem, repeated more than 10,000 times a month.

Ten people, ten thousand loads

At the Nova Scotia carrier, a ten-person team handled inbound loads in Trimble TruckMate. The tender arrived, someone read it, and the shipment became a record the operation could use. This happened throughout the day. Retirements threatened to take experienced people out of the process, while a Canadian labor shortage made replacing them difficult.

Hiring another person would address the volume. It would not immediately replace the knowledge. A new employee can learn where to enter a number much faster than they can learn which customer’s number needs interpreting. The cost of losing an experienced operator therefore extends beyond an empty chair. Someone else has to reconstruct the decisions that chair used to produce.

Consider how misleading the label “load entry” can be. It suggests a clerical interval between a customer’s request and the real business of transportation. Yet the record is where the request becomes actionable. Get its assumptions wrong and the operation starts with a mistake already built in.

The challenge for Eassons was to preserve capacity as people left without making every departure a fresh apprenticeship. Automating the keystrokes would help only if the system could also carry forward the reasoning behind them.

The customer sends a request, not a database

Unstructured tenders are a stubborn starting point. Customers communicate in formats that suit their own businesses. A carrier then has to translate those communications into its system. The apparent simplicity of a request conceals two separate jobs: finding the shipment details and deciding how to apply them.

That distinction matters. Reading a document can reveal the requested pickup. It cannot, by itself, establish the customer’s delivery rules. Extracting a weight does not settle how that account expresses weight. A clean transcription can still produce a bad load if it faithfully copies information under the wrong assumptions.

The recipe cards sit precisely at that junction. They turn a customer’s shorthand into operational instructions. They are a record of the questions the paperwork leaves unanswered, accumulated through the practical business of serving accounts.

This is why tribal knowledge becomes an automation barrier. It is scattered across documents, habits and experienced employees. People can consult each other when something seems odd. A system needs those judgments made explicit enough to use. The work begins by asking what the operator knows at each decision, rather than merely recording what the operator clicks.

The agent had to finish the job

Pallet’s agent starts with the tender, reading the unstructured request and extracting shipment details. It checks for duplicates against TruckMate. It enriches the information through APIs, retrieves the identifiers and schedules it needs, applies customer rules, builds the appropriate parent-child load structure and posts the finished load into TruckMate. [1]

The sequence is the point. A tool that stops after extraction leaves the employee to do the checking, lookup and construction. It might shorten the first part of the task while preserving the dependency on a human for everything that makes the record usable.

A duplicate check asks whether this request should become a new load at all. Enrichment connects the words in the tender to records the system recognizes. Customer rules shape the result. Parent-child creation gives a complex shipment the structure it needs. Posting completes the handoff from incoming communication to an operational record.

Each step closes a different gap. Taken together, they describe a job, rather than a feature. The agent’s useful output is a finished load in the existing transportation system. A person should not need to collect a pile of extracted fields and then perform the rest of the work.

There is also a practical discipline here: the automation has to meet the business where its work already happens. TruckMate remains the destination. The incoming request can be messy; the completed record must be something the operation can use.

Fresh chicken was the proving ground

The first workflow handled fresh chicken. It was a revealing place to start. Temperature settings and delivery schedules are consequential when the freight is perishable. Multiple stops add another layer: the system must preserve the relationships within the shipment as it creates the loads.

An easy demonstration can hide missing knowledge. A demanding workflow brings it into view. If a system can read a tender but cannot resolve the customer’s rules, the gap appears before the finished load reaches the transportation system. The recipe cards give that gap a concrete form.

Learning the workflow therefore means learning its exceptions as well as its normal path. Which instruction applies to this account? Which detail changes the calculation? Which schedule belongs to the delivery? Those questions are part of the job, even when the employee answers them without pausing.

Pallet reports that production deployment took 40 days. That interval matters because it separates a demonstration from a working process. The agent had to reach the point where incoming tenders could become completed loads in the system Eassons actually used. The first customer supplied the foundation for what came next. [1]

98% is a handoff, not a magic trick

The reported outcome was 98% touchless load building and 85% savings on load-entry costs. Those are different measures. One describes how often the workflow runs without human intervention; the other describes the expense of performing the work. Neither should be mistaken for a claim that every transportation task has been automated. [1]

The remaining cases have somewhere to go. New edge cases are escalated to people. That route is part of the design: the agent handles the established workflow, and the team deals with situations that require attention. A touchless percentage becomes useful when there is a reliable way to handle the cases outside it.

To make the ratio tangible, picture 100 load-building attempts at the reported rate. About 98 would proceed without a person touching the workflow. About two would need intervention. This is an illustration of the percentage, not a separate measurement of Eassons’ operations.

The change is in how attention gets allocated. Instead of looking at every tender because every tender needs entry, employees can concentrate on the requests that break the pattern and the customer conversations that deserve time. The cards helped preserve the repeatable decisions; people remain available for the decisions that have not yet become repeatable.

The second customer changes the economics

A first deployment can be impressive and still be difficult to repeat. Every additional customer might bring another long implementation. Eassons’ next result is therefore essential to the story: after the initial workflow, additional customers could be onboarded within 48 hours, according to Pallet’s case study. [1]

The difference between 40 days and 48 hours is not evidence that every future workflow will be simple. It shows what happened when the initial load-entry process became a foundation for expansion. The agent already had a destination, a sequence of actions and a way to involve people. A new account brought new instructions into an established process.

That is the expansion engine hidden inside the recipe-card holder. The cards differ from customer to customer, but the reason for having them is consistent. Each account needs its own rules applied to a familiar job. Capture the job once, then teach the differences.

The result makes the next customer a more manageable undertaking. It also changes the value of discovering an exception. An exception is no longer merely an interruption to someone’s day; it identifies another instruction the workflow may need. Human involvement supplies the boundary of what the agent can currently handle and the practical material for extending it.

What leaves the desk, what stays with the team

Eassons is adding agents for load execution, taking the work beyond the initial entry process. That is a new scope of work, not a result already established by the 98% figure. The load-entry deployment provides the starting point: a working example of turning incoming requests and account knowledge into completed action. [1]

“

Pallet is automating our button-pushing, so our team can focus on high-touch account management and sales.

Will Easson VP Continuous Improvement, Eassons

The recipe-card holder gives that ambition a more interesting meaning. The knowledge on the cards was valuable because it let the company serve customers in their particular ways. Moving it into a workflow does not make that knowledge less valuable. It makes it available without requiring the same experienced person to apply it to every incoming load.

An employee can leave a desk. A customer can send an awkward tender. A familiar request can contain an unfamiliar detail. A durable process needs a response to all three. At Eassons, the response began with the small, physical record of what the team already knew. The agent’s first essential lesson was written on paper.