Skip to main content

Conversational AI

In development

AI Chatbots

Deploy freight-aware assistants for internal knowledge, customer service, shipment support, and quoting workflows.

What this service does

Build grounded internal and customer-facing chat assistants for freight questions, shipment support, quoting, and guided workflows.

We do not force freight forwarders to replace the systems that run their business. We connect their technology, improve their data, redesign their workflows, and build AI around the realities of freight forwarding.

Who this is for

Operations, customer service, sales, pricing, and IT.

The problem

A generic chatbot on freight data is a confident source of wrong answers.

Freight questions depend on which customer is asking, which shipment they are entitled to see, and which SOP applies to that lane. An assistant without grounding, citations, and record-level permissions will answer anyway — and the operation absorbs the cost of the answer being wrong.

The same shipment status question asked and answered by hand, dozens of times a day.

Answers that vary by coordinator because the SOP lives in someone’s head.

No citation, so nobody can check whether an answer came from an approved source.

Quote intake that arrives incomplete and bounces back and forth to get filled in.

No permission model, so a customer-facing assistant risks exposing another customer’s record.

What the service includes

What we build.

Internal knowledge assistant

Answers staff questions from approved SOPs, policies, and operating documents, with citations back to the source so the answer can be verified.

Customer shipment assistant

Answers permitted shipment questions against record-level access rules, so a customer sees their shipments and only their shipments.

Rating and quoting copilot

Guides a complete quote intake, surfaces reviewable rate options with the assumptions stated, and leaves the pricing decision with a human.

Citations and assumptions

Every substantive answer carries its sources, and any assumption the assistant made is stated rather than buried — the operator can see what the answer rests on.

Structured handoffs

When the assistant is uncertain or the request is out of scope, it escalates with the context already collected instead of dumping the customer back to the start.

Evaluations

A test suite of real freight questions with expected grounding, run before every release so a change to prompts, retrieval, or model is measured rather than hoped for.

Freight workflows

Where it applies in your operation.

  • Cited exception guidance
  • Permitted shipment milestones
  • Complete quote intake
  • Reviewable rate options

The outcome

Answers that cite their source, or escalate.

Routine questions are handled consistently and traceably. The assistant is scoped to a risk tier, grounded in approved data and SOPs, and measured on grounded-answer rate rather than conversation volume.

How an engagement works

The engagement.

Engagement process — Define, Ground, Experience, Pilot and scaleA 4-step sequential engagement process: Define → Ground → Experience → Pilot and scale.01DefineAgree the audience, the scope,and the risk tier for eachassistant. Decide what it mayanswer, what it must escalate…02GroundConnect approved knowledge andpermitted records, build theretrieval and permissionmodel, and set the citation a…03ExperienceDesign the conversation flows,the escalation paths, and thestructured handoff, then wirethe assistant into the surfac…04Pilot and scaleRun with a limited audienceagainst the evaluation suite,review corrections andescalations, then widen scope…
01
Define

Agree the audience, the scope, and the risk tier for each assistant. Decide what it may answer, what it must escalate, and what it may never touch.

02
Ground

Connect approved knowledge and permitted records, build the retrieval and permission model, and set the citation and assumption behaviour.

03
Experience

Design the conversation flows, the escalation paths, and the structured handoff, then wire the assistant into the surfaces the audience already uses.

04
Pilot and scale

Run with a limited audience against the evaluation suite, review corrections and escalations, then widen scope only where measured performance supports it.

What you receive

Deliverables you keep.

  • Risk-tier definition per assistant
  • Conversation map
  • Retrieval and permission plan
  • Working assistant
  • Evaluation suite

Reference architecture and boundaries

Built alongside your systems of record.

The exact stack should follow the client's systems, data rights, skills, budget, and operating model. A useful reference architecture separates transaction authority from data, intelligence, action, experience, and governance layers.

Reference architecture — five layers, systems of record to governanceLayer stack from systems of record at the foundation up through integration and data, intelligence and action, experience, and governance at the top, with intelligence and action highlighted as the focal layer.OVERSIGHTTRANSACTIONS05GovernanceIdentity, permissions, evaluations, traces, incidents, retention, cost, andcontinuous improvement.04ExperienceDashboards, portals, intranet, chat, email, voice, and human-review queues.03FOCALIntelligence and actionRetrieval, semantic definitions, agents, deterministic rules, andpermissioned tools with validation and approvals.02Integration and dataAPIs, webhooks, files, events, normalization, lineage, quality monitoring,and governed freight entities.01Systems of recordTMS, CRM, accounting, rating, carrier, customer, email, telephony, anddocument systems remain authoritative for transactions.FOCAL LAYERIntelligence and action is where agents and rules touch your data — behind explicit permissions and human approval.

Security and human control

The principles every build follows.

  • Use least-privilege identities and explicit tenant, role, and record-level access.
  • Treat email, documents, web content, and model output as untrusted until validated.
  • Keep systems of record authoritative; agents use controlled APIs rather than casually editing copied data.
  • Require human approval for consequential customer, financial, compliance, or system-write actions until reliability is demonstrated.
  • Retain logs, evaluations, failures, approvals, and ownership information for review.

How success is measured

Measured against a defined KPI.

We baseline these before the build starts, so the improvement is a measurement rather than an impression.

Grounded answer rate

Escalation rate

Self-service resolution

Quote intake completeness

Correction rate

User satisfaction

Cost per conversation

Frequently asked questions

The questions forwarders ask first.

Is this a replacement for our existing systems?

Usually no. The service is designed to connect and extend the systems of record the forwarder already uses.

How do you prevent unsafe automation?

Start with narrow workflows, explicit permissions, validation, evaluation, human approval, auditability, and a clear rollback or escalation path.

What is required before publishing results or case studies?

Replace general language with verified client evidence, named systems, measured baselines, and approved proof assets. We do not imply integrations, certifications, or outcomes that have not been confirmed.

Source notes

These references support the industry and technical framing on this page. They do not validate claims about any specific client. Claims about client results, integrations, or compliance posture are published only with verified project evidence.

Ready to scope it?

No commitment to start. We'll look at your systems and workflows, then come back with a fixed-scope plan.