A routing-platform decision should not begin with a feature comparison. It should begin with the operation: the work your team performs, the commitments it must keep, the constraints it must respect, and the evidence already contained in years of route history.

Many transportation leaders are reassessing the tools they use for strategic planning and daily routing. Some are replacing an aging environment. Others are trying to get more value from a platform they already own. Still others are deciding whether they need a large routing suite at all.

The tempting first move is to schedule demonstrations and compare product lists. That may feel like progress, but it often pushes the most important questions to the end of the process. Before evaluating software, a business should understand what its routing operation actually needs the software to do.

A routing platform is part of an operating model

Routing technology does more than sequence stops. It sits inside a network of customer promises, warehouse cutoffs, vehicle capacities, driver schedules, service-time assumptions, delivery windows, geographic restrictions, dispatch decisions, and financial expectations.

When those operating rules are incomplete, inconsistent, or poorly understood, even capable software will produce results that the organization struggles to trust. A replacement platform does not automatically repair unclear service standards, weak location data, unrealistic planned times, or processes that depend on knowledge held by one experienced planner.

This is why platform selection must begin with operating truth. The objective is not to find the tool with the longest feature list. It is to define the smallest complete set of capabilities that can support the way the business needs to plan, execute, measure, and improve.

Your existing routing data is the starting point

Organizations that have used a routing platform for years already possess a valuable planning asset: their own operating history. Routes, stops, orders, service windows, planned miles, actual miles, planned time, actual time, equipment assignments, and recurring exceptions can reveal far more than a scripted demonstration.

That history can help answer questions such as:

• Which constraints genuinely shape the operation, and which are merely inherited settings?
• Where do planned routes consistently differ from operating reality?
• Which service-time or customer-location assumptions need to be corrected?
• What decisions belong in strategic planning, and what must happen during daily execution?
• Which capabilities are essential, and which would add cost without solving a meaningful problem?

Analyzing these questions before procurement creates a defensible requirements document. It also gives leadership a baseline against which any proposed solution can be evaluated.

Where RouteLab fits

Four Square Group uses RouteLab technology developed by Wellwood Technologies to help turn operating history into structured analysis. RouteLab provides a flexible environment for working with transportation data, examining route and stop performance, comparing planned and actual results, and investigating the assumptions behind an operation.

The value is not a generic score. It is the ability to connect a business question to the underlying evidence. A leadership team can begin with the operation it has today, establish a trustworthy baseline, identify the gaps that matter, and define the requirements for the next move.

RouteLab does not force the conclusion that every organization needs to replace its current platform. It helps create the clarity required to make that decision responsibly.

Three valid paths forward

A disciplined assessment may lead to one of three outcomes.

1. Improve the environment you already have

Sometimes the technology is not the primary limitation. Better master data, stronger planning standards, targeted configuration changes, improved integrations, and clearer operating routines may deliver more value with less disruption than a replacement.

2. Structure a platform replacement

When replacement is justified, the analysis becomes the foundation for selection and migration. The organization can compare vendors against real requirements, protect critical operating rules, prioritize integrations, and validate the new environment against a known baseline.

3. Shape a new planning approach

Some organizations need a more focused strategic-planning capability rather than another heavyweight suite. A data-centered approach can support network questions, scenario development, operating-model changes, and future planning capabilities without assuming that every planning problem requires the same product architecture.

Strategic planning and daily routing are related, but different

Strategic planning asks how the operation should be designed. It examines questions such as territory structure, resource requirements, service frequency, delivery-day patterns, capacity, network balance, and the effect of changing business rules.

Daily routing asks how today’s work should be executed. It must account for the orders, people, vehicles, restrictions, and exceptions present now.

The two disciplines should share a dependable data foundation, but they should not be confused. A company can buy an excellent daily-routing tool and still lack a strong strategic-planning process. It can also build an elegant long-range model that fails when its assumptions reach the front line.

FSG helps connect those layers so strategic choices remain grounded in operating reality and daily execution produces evidence that improves the next planning cycle.

Why involve Four Square Group before the RFP?

For nearly seven years, FSG has supported complex Roadnet environments. Our broader last-mile experience spans strategic planning, routing, implementation, configuration, advanced training, integrations, troubleshooting, data extraction, analytics, and ongoing operational support.

That experience matters because a routing-system decision is never only technical. The work must account for planners and dispatchers, delivery teams, customers, warehouse processes, leadership expectations, integration dependencies, and the organization’s ability to sustain the change.

FSG serves as the consulting partner. We help frame the business question, establish the operating baseline, separate requirements from preferences, and carry the chosen path through implementation and adoption. RouteLab gives us a practical technology foundation for analyzing the evidence behind those decisions.

Your operation should define the technology—not the other way around.

Start with a routing-decision assessment

Before scheduling another round of vendor demonstrations, start with the data and decisions that already define your operation. A focused assessment can establish the baseline, identify material gaps, clarify strategic and daily-routing requirements, and determine which path deserves investment.

If your organization is evaluating strategic-planning tools, replacing a routing platform, or deciding what to do with years of Roadnet data, talk with Four Square Group before you issue the RFP.

Already operating in Roadnet? Explore our Roadnet support and modernization capabilities.

An agent becomes useful when it can monitor a defined process,
collect evidence, apply rules, and move work toward an accountable
decision.

1. Daily operating exception brief

Most operating meetings do not suffer from a shortage of reports.
They suffer from too many numbers and too little investigative time.
A useful agent can compare today’s conditions with agreed
thresholds, connect an exception to its supporting records, and
separate a material service risk from routine variation.

The agent watches agreed measures, identifies material exceptions,
investigates contributing records, and prepares a prioritized
briefing for the morning operating meeting. The manager receives
fewer charts and a clearer starting point.

2. Route or shipment recovery assistant

Recovery work is a good candidate because it is time-sensitive and
context-heavy. The right response may depend on customer priority,
available capacity, delivery windows, driver hours, dock conditions,
and downstream commitments. The agent’s role is to assemble and
compare options—not to hide those tradeoffs behind one answer.

When service risk appears, the agent assembles order, route,
capacity, customer, and timing context; proposes recovery options;
and prepares communications for human approval.

3. Plan-versus-actual investigator

Traditional reporting shows that a variance occurred. Investigation
asks why it occurred, whether the evidence is reliable, and whether
the pattern is repeating. An agent can perform the first pass across
many routes or shipments and hand analysts a shorter, better-defined
list of questions.

The agent reconciles planned and captured events, separates measured
from assumed timestamps, groups recurring variances, and points
analysts toward the conditions with the greatest operating effect.

4. Customer inquiry evidence pack

This workflow can improve speed and consistency without automating
the customer relationship. The evidence pack might include the
order, appointment, dispatch history, location events, delivery
record, related communications, and any missing evidence. A person
still decides how to explain the situation and what commitment to
make.

The agent collects the approved facts behind a delivery or service
question, identifies missing evidence, and drafts a consistent
response. Customer service retains ownership of the message.

5. Performance-review preparation

Preparation is often distributed across dashboards, notes, safety
systems, and local spreadsheets. An agent can organize that material
around an agreed review period and flag where context is missing. It
should never reduce a person to a score or infer sensitive
conclusions that the approved evidence cannot support.

The agent assembles trend, exception, coaching, safety, service, and
productivity evidence into a structured review packet while
preserving source quality and manager judgment.

The best first agent does not replace an operator. It returns time,
context, and consistency to that operator.

Score the candidates

Evaluate frequency, time consumed, data availability, decision
ownership, consequence, reversibility, integration difficulty, and
measurable value. A modest high-frequency workflow often creates a
better first result than a dramatic low-frequency decision.

Add two questions that are easy to overlook: Is there a named owner
who wants the output, and can the organization tell whether it
helped? A technically impressive workflow without an operating owner
becomes a demonstration. A workflow without a measurable result
becomes an opinion about productivity.

Run beside the current process

For an initial period, compare the agent-supported workflow with the
existing method. Record missed issues, unnecessary escalations, time
saved, acceptance, overrides, and outcome quality. Use that evidence
to decide whether the agent’s authority should expand.

A parallel run also exposes the tacit rules that rarely appear in a
procedure manual. When an operator rejects a recommendation, capture
the reason. That feedback may reveal a missing data element, a local
customer agreement, or an exception policy worth formalizing.

Choose useful over impressive

The best first workflow often looks modest from the outside. It may
save thirty minutes every morning, make one recurring decision more
consistent, or prevent a small number of avoidable service failures.
Repeated across a network and sustained over time, that practical
value is more important than a dramatic demonstration that never
becomes part of daily work.

Replacement projects are sometimes necessary. They are rarely the
best prerequisite for learning where AI creates value.

Transportation, warehouse, ERP, telematics, CRM, and workforce
systems often contain years of configured rules and organizational
knowledge. The challenge is that their data remains fragmented and
their workflows stop at system boundaries.

Build beside the core

Fragmentation creates familiar manual work: exporting reports,
matching identifiers, copying results between screens, assembling
meeting packets, and asking experienced people to explain the same
exceptions repeatedly. These are often the best starting points—not
because the systems failed, but because valuable work lives between
them.

A controlled extract can feed a separate decision layer where FSG
reconciles records, calculates measures, and tests AI-supported
workflows. The production system continues to run the operation
while the new layer observes and supports it.

Begin read-only

“Beside” is both an architectural and organizational choice. The new
capability receives only approved data, documents its
transformations, and returns an output through an agreed path. It
does not quietly become a second dispatch, inventory, or financial
system.

Read-only use cases—exception summaries, trend investigations,
plan-versus-actual analysis, customer risk identification, and
briefing preparation—can produce value without creating a new
transaction path.

Add integration in stages

A read-only pilot can still change daily work. A morning brief might
identify the five exceptions most likely to affect service, connect
them to the relevant orders and routes, and show why each was
selected. The manager owns the response, but gathering context takes
far less time.

1. Deliver a human-reviewed report or alert.
2. Prepare a structured action for approval.
3. Send an approved update through a documented interface.
4. Automate narrow, reversible actions after controls and evidence
   mature.

Respect the system of record

Each stage should earn the next. Track whether people accept the
recommendation, how often they edit it, which cases escalate, and
whether outcomes improve. Integration depth can then follow proven
operating value instead of preceding it.

The intelligence layer should not create competing truth. Each
output must identify source systems, transformation logic,
freshness, and the authoritative destination for approved changes.

Modernization can begin with better decisions—even when the
underlying platforms remain in place.

Let value guide the roadmap

Identifiers deserve particular attention. Customer, location, order,
route, employee, and asset records need controlled matching rules.
If an intelligence layer joins the wrong records confidently, a
sophisticated model simply delivers the wrong answer faster.

Successful early use cases reveal which integrations, data
improvements, or platform changes are worth funding. This turns the
technology roadmap into an evidence-based investment sequence rather
than a speculative transformation program.

Logistics operations already delegate authority. Dispatchers, planners, drivers, supervisors, and systems each act within defined limits. Those limits are not a constraint on performance; they are part of how a dependable operation works.

AI agents need the same discipline. The useful question is not whether an agent is autonomous. It is autonomous to do what, under which conditions, using whose data, and with what consequence?

That distinction matters because “use AI” can describe very different activities. Summarizing yesterday’s exceptions is not the same as changing a customer’s delivery commitment. Drafting a corrective-action note is not the same as sending it. Recommending a route change is not the same as releasing a new plan to drivers.

Governance becomes practical when it describes those differences in operating terms.

Authority is an operating decision, not a software setting

Organizations often discuss autonomy as though it were a feature that is either enabled or disabled. In practice, authority should be assigned action by action. The same agent may be allowed to complete one low-risk internal task while remaining recommendation-only for a customer-facing decision.

A useful design begins with three questions:

• What is the agent allowed to know? Define the approved systems, records, fields, and time periods it may use.
• What is the agent allowed to do? Separate observation, analysis, preparation, and execution into explicit permissions.
• When must the agent stop? Name the conditions that require escalation to a specific person or role.

This turns governance from a broad policy statement into an operating agreement that leaders, operators, IT, and security can inspect together.

Five levels of agent authority

Most operational AI use cases can be described through five levels of authority. The levels are cumulative in capability, but they do not need to be cumulative in permission. An agent can be highly capable while still being intentionally restricted to observation or recommendation.

1. Observe

The agent reads approved data and monitors defined conditions. It may identify late departures, missed scans, unusual service times, inventory mismatches, or recurring exceptions. It does not explain the condition or propose an action unless that authority has also been granted.

Operational example: monitor planned and actual route activity and flag stops that have crossed a defined service-risk threshold.

2. Explain

The agent assembles relevant evidence and summarizes likely causes. A useful explanation should show its work: the source records used, the rules applied, the information that is missing, and the degree of confidence in the conclusion.

Operational example: explain that a late route was driven by a delayed start, two extended service events, and a customer closure—not simply label the route “inefficient.”

3. Recommend

The agent proposes a next action, alternatives, and tradeoffs. The person responsible for the outcome still makes the decision. Recommendations should be specific enough to act on and should make consequences visible.

Operational example: recommend moving selected stops, adjusting a sequence, or contacting a customer, while showing the expected effect on capacity, service, and downstream commitments.

4. Prepare

The agent drafts the work required to carry out an approved decision. That may include a customer message, a task, a revised plan, a transaction, or a structured record for review. Preparation removes administrative burden without removing accountability.

Operational example: prepare a revised dispatch plan and the related customer notifications, but hold both for supervisor approval.

5. Execute

The agent completes a narrowly defined and auditable action. Execution should not mean unlimited discretion. It should mean that the action, conditions, data, limits, evidence, and recovery path are all clear enough to permit the system to act.

Operational example: automatically annotate an internal exception record when an approved rule is met, while escalating any customer-impacting change for review.

Most first deployments should concentrate on Observe, Explain, Recommend, and Prepare. Those levels can reduce analytical and administrative burden while keeping consequential decisions with a person.

Use consequence to set the boundary

The right level of authority depends on the consequence of the action—not on the sophistication of the technology or the enthusiasm surrounding it.

Before granting execution authority, evaluate:

• Customer commitment: Could the action change a delivery promise, price, service level, or communication?
• Financial impact: Could it release a payment, create a charge, change labor, or commit capacity?
• Safety: Could it affect a driver, employee, customer, facility, or physical asset?
• Reversibility: Can the action be reviewed and undone before it creates an external consequence?
• Data sensitivity: Does it expose personal, customer, employee, commercial, or regulated information?
• Employment impact: Could it influence coaching, scheduling, discipline, hiring, or compensation?
• Regulatory exposure: Is the action governed by a contract, policy, law, or audit requirement?

Automatically tagging an internal record is different from changing a delivery promise. Preparing a payment for approval is different from releasing it. Summarizing a performance pattern is different from making an employment decision.

As consequences rise, the evidence should become stronger, the rules narrower, the approval path more explicit, and the recovery plan more credible.

Make the evidence visible

An operator should be able to understand why an agent reached its conclusion. A polished answer is not enough. The operating evidence should remain available for inspection.

A useful evidence package answers:

• Which source records were used?
• What business rules or thresholds were applied?
• What information was unavailable or conflicting?
• How confident is the system, and why?
• What alternatives were considered?
• What will happen if the recommendation is accepted?

The answer should also fit the person who must act. A dispatcher may need the affected stops, current vehicle position, remaining capacity, and triggering rule. An auditor may need the underlying records, event history, model version, and approval trail. Those views can come from the same controlled evidence package without forcing every user into the same interface.

Design escalation as a feature

A dependable agent knows when to stop. Missing data, conflicting records, low confidence, unusual financial exposure, safety conditions, or a policy exception should route work to a named role with the relevant evidence attached.

“Human in the loop” is meaningful only when it identifies a real owner with a real decision. A generic promise that someone can intervene is not an escalation design.

Good escalation also protects attention. If every minor anomaly creates a new alert, the workflow simply replaces one burden with another. Teams should define what is material, group related issues, suppress duplicates, and distinguish an informational exception from a decision that truly needs intervention.

Start with a controlled pilot

A first pilot should be useful enough to matter and bounded enough to understand. Begin with recurring work that consumes expert attention, has accessible evidence, and ends in an outcome the organization can measure.

A practical sequence is:

1. Baseline the work. Measure the current volume, cycle time, exception rate, review effort, and operating result.
2. Run in observation mode. Let the agent produce evidence without changing the workflow. Compare its findings with experienced operators.
3. Add recommendations or prepared actions. Record acceptance, edits, overrides, and the reasons behind them.
4. Expand authority only when earned. Consider narrow execution after the evidence, rules, escalation path, and recovery method have proven dependable.

This staged approach creates value early. A team does not need to wait for full autonomy to reduce research, reconciliation, documentation, and preparation effort.

Measure the operating result

Technical accuracy is necessary, but it is not the entire outcome. The agent should improve the workflow and support responsible judgment.

Useful measures may include:

• Recommendation acceptance and override rates
• False-positive and missed-exception rates
• Escalation volume, usefulness, and response time
• Cycle-time reduction
• Operator review effort
• Data-quality defects uncovered
• Customer, service, financial, or operational outcomes appropriate to the use case

Review the measures by action and consequence. A high acceptance rate for internal summaries does not prove that the agent should be allowed to change a customer commitment. Authority should expand because evidence supports the specific action—not because the system performed well somewhere else.

What a well-governed deployment looks like

A well-governed AI workflow is not defined by how much authority it has. It is defined by whether everyone understands the boundary.

The business knows what outcome it is trying to improve. Operators can inspect the evidence. IT and security know what data and systems are in scope. Escalations reach a named owner. Consequential actions retain human accountability. Results are measured, and authority changes only when operating evidence justifies the change.

Governance in one sentence: Give each agent the minimum data and authority required for the use case, make its reasoning inspectable, and keep a named human accountable for consequential outcomes.

Put AI to work without losing control

The strongest AI opportunities usually begin with the work—not with the model. Define the business question, the evidence, the operating owner, and the decision boundary first. Then choose technology that fits that design.

If your team is deciding where an AI workflow should observe, explain, recommend, prepare, or execute, Four Square Group can help translate the opportunity into a practical operating model. We bring operational leadership, connected-system thinking, analytics, and implementation discipline to the work.

Talk with Four Square Group about a controlled AI use case.

The security conversation around AI often begins with the wrong
binary choice: allow a new model inside the enterprise or prohibit
the work entirely. A third path is frequently more practical.

A logistics organization can create a controlled copy of approved
operational data, remove fields the analysis does not require,
transfer it through an agreed channel, and analyze it inside an
isolated environment built for the engagement. The model never needs
direct access to the transportation, warehouse, ERP, customer, or
fleet system running the operation.

Start with the decision—not the dataset

This reverses a common technology-first sequence. Instead of moving
a broad dataset and then searching for a use, the organization names
a recurring decision and maps the minimum evidence required to
improve it. That creates a defensible reason for every selected
field and a clear test for whether the engagement is working.

“Give us all the data” is not a responsible starting point. Define
the question first. Which decision should improve? Who owns it? What
evidence is required? How current must the answer be? These
questions determine the minimum data needed.

Data minimization reduces exposure and usually improves the work. A
narrow dataset is easier to validate, document, refresh, and delete
than an open-ended replica of the enterprise.

Design the boundary with IT

A good design makes responsibilities visible. The business owner
defines the use case and acceptable outcome. Data owners approve the
selected records. IT approves the transfer and environment. Security
reviews identity, access, retention, providers, and incident
handling. The consulting team documents transformations and operates
within those decisions.

The phrase “outside the firewall” should not mean “outside
governance.” It means the engagement uses a separately controlled
environment rather than embedding unproven AI tooling in production.
The customer’s IT and security teams should approve the design.

• Identify data owners and classify the selected fields.
• Remove, tokenize, or mask identifiers that are not essential.
• Encrypt transfers and stored data using agreed mechanisms.
• Limit access by role and keep an access record.
• Define model providers, data-use settings, regions, and
  subprocessors.
• Set retention, archival, and verified-deletion expectations.

The refresh process deserves the same care as the first extract.
Teams should know who initiates it, how completeness is checked,
what happens when a file is late or malformed, and how prior
versions are handled. An automated pipeline without these controls
can reproduce a data-quality problem more efficiently.

The goal is not to route around IT. It is to give IT a boundary it
can inspect, approve, and govern.

Separate analysis from action

Separation creates room to evaluate both accuracy and usefulness.
Does the agent identify the same material exceptions as experienced
operators? Does it provide enough evidence? Does it reduce
preparation time? Does it introduce noise? These questions can be
answered before granting any ability to alter a production record.

An early agent should usually observe, calculate, summarize, and
recommend. It should not silently change routes, inventory, customer
commitments, payroll, or financial records. Consequential actions
require explicit authority boundaries and human approval until
evidence supports a different model.

Build the return path deliberately

Returning a result is not the same as integrating a system. A
human-reviewed briefing may be the right permanent design for a
high-consequence decision. A governed API may be appropriate for a
stable, high-frequency calculation. The output format should follow
the workflow, its risk, and the person accountable for the next
step.

Value can return as a report, validated dataset, dashboard, API
response, workflow recommendation, or approved system update. Each
return path has a different risk profile. Starting with
human-reviewed outputs allows the organization to learn before
automating execution.

Plan the end before the beginning

Every controlled environment needs an exit plan. Define what will be
retained, returned, archived, or deleted when the pilot ends; how
deletion will be verified; and which documentation the customer
receives. A clean closeout is part of trustworthy delivery, not an
administrative detail added after the analysis.

Logistics companies are surrounded by data. The hard part is
determining which version of an event is authoritative enough to
support a decision.

A planned route, dispatched route, GPS trace, proof-of-delivery
timestamp, customer order, warehouse scan, and invoice can all
describe the same work differently. AI can connect these records,
but it cannot decide what “actual” means without business rules.

1. Define the decision contract

An operational decision is rarely supported by one perfect record. A
late-delivery review might use a planned arrival, a driver status, a
vehicle position, a warehouse scan, and a customer signature. Each
record can be accurate for its original purpose while still
disagreeing with the others. The work is not simply to collect more
data; it is to decide which evidence answers the question at hand.

State the decision, owner, timing, inputs, acceptable uncertainty,
and required evidence. A daily exception agent and a quarterly
network study should not share the same freshness or precision
standard.

2. Preserve source meaning

Consider the difference between a dispatcher deciding whether to
intervene today and a finance leader evaluating a quarterly trend.
The dispatcher needs timely evidence and a clear exception
threshold; the quarterly review needs consistent definitions across
every week. A written decision contract prevents one metric from
quietly serving two incompatible purposes.

Do not flatten every field into a universal label too early. Keep
source identifiers, timestamps, time zones, status semantics, units,
and capture quality. Transformation should make meaning clearer—not
erase provenance.

3. Reconcile before predicting

Provenance makes an answer explainable later. Retain the original
field, its source, when it was captured, and whether it was
measured, inferred, corrected, or entered manually. A polished
metric that hides those distinctions may appear precise while giving
an operator less information than the raw records did.

Many valuable insights come from resolving disagreement between
systems: planned versus executed, ordered versus delivered,
scheduled versus clocked, or system-generated versus human-entered.
Reconciliation is often more valuable than a complex prediction.

4. Publish quality with the answer

Disagreement can itself be operationally useful. Repeated gaps
between planned and actual departure may point to loading
constraints. Customer timestamps that differ from telematics may
reveal a process issue rather than poor service. Before predicting
the future, teams should understand what their systems say about the
present.

A trustworthy output includes coverage, freshness, exclusions, and
confidence. If 12 percent of route starts are assumed rather than
measured, the decision-maker should see that distinction.

An AI answer without lineage is an opinion with excellent
formatting.

5. Create a reusable decision layer

Quality does not need to become a technical appendix. Coverage
period, percentage of measured events, missing records, exclusions,
and last refresh can materially improve a manager’s judgment. They
also help distinguish a real operating change from a change in data
collection.

Once definitions and checks are stable, publish them as reusable
tables or governed services. Agents, dashboards, analysts, and
applications should draw from the same operational contract rather
than rebuilding logic independently.