Freight quote intake with a voice agent: what to capture

For a freight broker, logistics operator or marketplace team of 50-100 people, an inbound quote call often sits between sales, capacity and customer service. The caller may have only a lane and deadline while the person who can confirm a truck is in another queue. A voice agent is most useful when it turns that conversation into a complete, reviewable request. The goal is faster qualification with accurate capacity information, not an automated rate desk that fills gaps by guessing. The intake record should make uncertainty visible so a pricing or operations teammate knows exactly what still needs confirmation.

Start with qualification, not pricing

The opening questions should establish whether a request is actionable and where it belongs. Ask whether the caller is a shipper, broker, carrier or existing customer, then capture company, caller, callback, email and load or account reference. Confirm the number and spelling aloud. This context determines whether the next step belongs with sales, operations, account management or carrier coverage. Capture the caller's preferred contact method and whether someone else should be copied, but do not treat a caller's role or company affiliation as verified until it matches an approved record or a human confirms it.

Capture the fields that change the answer

• Lane: origin and destination, city, state or country, stops and any cross-border requirement.
• Equipment: class, dimensions, weight, commodity, temperature, hazmat status and special handling.
• Availability and timing: ready date and time, pickup and delivery windows, time zones, appointments and flexibility.
• Commercial context: tender or quote deadline, accessorials, service level and whether a rate was discussed.

Make required fields explicit. If a caller does not know the weight or delivery window, record "unknown" and continue; do not make an assumption. A useful incomplete request is safer than a confident inaccurate one. The broader logistics workflow should define mandatory fields for each service type. Separate a field that is unknown from a field the caller declined to provide, and preserve both states for the reviewer.

Validate lane, equipment and timing together

Ask lane questions in the order a person will use them. Normalize the origin and destination to a city, state or country, then ask for facility names, dock or appointment details and the sequence of any intermediate stops. A place name that sounds clear on a call may map to more than one location. When the caller gives a facility nickname, keep the spoken value and the normalized value separate until the match is confirmed. For multi-stop freight, record which commodity, quantity and accessorial applies to each stop rather than attaching every detail to the first location.

Equipment validation is more than selecting dry van, reefer or flatbed. Capture requested equipment, trailer dimensions, weight and unit, commodity, temperature range, loading method, hazmat status and any appointment or handling constraint. Ask whether the requirement is strict or whether an equivalent option is acceptable. This lets capacity staff distinguish a hard constraint from a preference. It still does not establish that equipment is available: the record needs a separate capacity status such as requested, unknown, system-reported or human-confirmed, with the source and time of the status.

Timing needs the same discipline. Record the ready date separately from the pickup appointment, delivery appointment and quote deadline. Store each location's local time zone, note whether a window is hard or flexible, and capture the caller's interpretation of words such as "early," "same day" or "overnight." If the sequence appears infeasible or the deadline conflicts with the requested service, mark it for review and explain why. The agent should ask a clarifying question or hand off; it should not silently widen a window or imply that a carrier can meet it.

Use a compact quote intake matrix

Use a quote-ready record, not a transcript

A summary should be structured enough for the next person or system to act without replaying the call. For example: "Shipper requests one dry van from Columbus, OH to Nashville, TN; pickup Tuesday 08:00-10:00 Eastern; delivery Wednesday by 15:00 Central; 42,000 lb; packaged food, non-hazmat; quote needed by Monday at noon; callback number confirmed; appointment required." Store each value in its own field, with source and confidence where your tools support it. Keep the verbatim note as context, but make the lane, windows, units and exceptions machine-readable.

Before write-back, read the summary to the caller and resolve contradictions: a 42,000 lb load is not the same as 42,000 kg, and "Tuesday morning" needs a time zone and window. Ask the caller to confirm the practical next step as well as the facts: is the request for a written quote, a live rate conversation, a carrier search or an update to an existing load? If the caller changes a detail later, update the existing request rather than creating a second lead. Record who changed it, when and which field changed, so operations can distinguish a new opportunity from a correction.

Give the record a lifecycle state that reflects the work still required. Useful states might include intake in progress, ready for review, awaiting caller detail, pricing review, capacity review, handoff pending, follow-up scheduled and closed. The names can differ by system, but the meaning should be documented. A record marked ready for review should not look like a quoted load, and a record marked capacity confirmed should identify the approved source rather than relying on a sentence in the call note.

Verify the caller and carrier context

Caller context changes the check. For carriers, collect the legal or trading name, an approved identifier such as an MC or DOT number where relevant, equipment, operating area, current or next available location when appropriate and availability window. Ask whether the caller is offering capacity for this request or asking about a future opportunity. For shippers and brokers, capture the account or company reference, request owner and any existing load or quote identifier. Treat identifiers and capacity statements as caller-provided until the connected system or a human verifies them.

Use a known TMS or CRM record to match the caller. A missing match, conflicting company information or unusual access request should create review, not a trusted profile. The agent can confirm what it heard, but should not claim a carrier is approved, insured, assigned or available without an approved source. Do not fill a missing carrier identifier from memory or from a similar company name. When two records are plausible matches, preserve the ambiguity and send it to the queue that owns vendor or account verification.

Keep capacity uncertainty explicit

Capacity is a changing operational fact, not an inference from a carrier saying it usually runs a lane. Store the source of any availability statement, the time it was checked and the equipment or date it applies to. A system may show a candidate, a carrier may express interest, or a dispatcher may confirm a particular truck; those are different states and should not collapse into "covered." If a connected source is stale, unavailable or inconsistent, say that the status needs human confirmation. The voice agent can collect a carrier's offer and create a coverage task, but the task owner decides whether it is usable.

Set clear boundaries and a human handoff

The agent can collect the request, repeat captured details, share an approved status from a connected system and create a follow-up task. It cannot invent capacity, hold a truck, confirm a tender, promise an appointment, quote an unapproved rate or accept an exception. Pricing, negotiation and accessorials trigger human handoff with a reason code. Include lane, equipment, timing, caller context, missing fields, requested outcome and approved data used. The handoff package should also state what the agent told the caller, what remains unverified and whether the caller is waiting, expecting a callback or continuing to source alternatives.

Route by responsibility, not round-robin. Send a shipper or marketplace lead to its account or lane owner; a carrier opportunity to capacity or vendor operations; an existing-load question to the load owner; and unmatched or urgent requests to a staffed review queue. Use an explicit fallback if the named owner is unavailable. Tell the caller whether it is transferring, creating a callback or recording a request for the next staffed window. When a human accepts the handoff, record the acceptance and first action; a task placed in a queue is not the same as a conversation completed.

Make follow-up ownership durable

Every unresolved request needs one accountable owner, even when several teams contribute. Write the owner or queue, the requested action, the due-by time in a clear time zone, the caller's preferred channel and the next contact window into the work item. Include a reason for follow-up, such as missing delivery details, pricing review, carrier verification or a failed transfer. If ownership changes, record the transfer rather than silently replacing the name. Close the loop with a disposition: quoted, not a fit, caller unavailable, duplicate, escalated, opted out or another documented outcome. This prevents a transcript from becoming an orphaned lead.

Design retries and after-hours handling

Define a stop condition. For a missed transfer, no answer or incomplete callback, store the result and retry only within the permitted contact window. Start with one follow-up attempt; reserve a second for high-priority requests or a caller preference. Stop after contact, opt-out, closure or the attempt limit. A failed write-back should create an operator exception, not a loop. Keep the attempt history on the same request, including the channel, timestamp, outcome and next eligible window.

After hours, capture the lane, deadline and urgency, then route only situations that meet a defined on-call rule. The rule should identify who may accept a live transfer, what information is required before waking that person and what happens when no one accepts. For everything else, provide the configured review window without promising an unstaffed response time. Confirm the callback number and the caller's time zone before ending the call. The telephony setup should make schedules, transfer destinations, voicemail behavior and failure states visible. A recorded request should carry an after-hours flag so the next reviewer understands why no live answer was given.

Write back once, then alert on exceptions

Map the intake to the correct object before enabling write-back. A new shipper inquiry may belong in a CRM lead, a carrier offer in a vendor or capacity record, and an existing-load call in the TMS load activity. Define which fields the agent may create, which it may update and which require approval. Use the phone number, account or load reference, lane and time window to find likely duplicates, then ask for review when the match is uncertain. The integration should be idempotent: a retried call or webhook must update the intended request rather than create a second work item.

Write the structured fields, source, call identifier, transcript link if permitted, confidence or verification state and next-step owner. If a required mapping fails, keep the intake available in an exception queue and tell the operator which field or system failed. Do not report a successful quote intake merely because the voice platform saved a transcript. Reconciliation between the voice record and the TMS or CRM should be part of pilot testing and ongoing review.

Pilot in controlled phases

Start with a narrow intake scope: one business line, a small set of equipment types and no pricing authority. In phase one, compare agent summaries with human notes and tune required fields. In phase two, enable TMS or CRM write-back and routing after field mappings, duplicate handling and error states are tested. In phase three, add selected after-hours calls, live transfers and carrier-specific flows. Keep a human review path throughout and expand only when call records show the added scope is understood.

Use entry and exit gates for each phase. Before live traffic, require an approved field schema, owner map, fallback queue, test cases and a pause procedure. Before write-back, require a reviewer to reconcile sample records against the source conversation and confirm duplicate and failure behavior. Before live transfers or after-hours coverage, require tested destinations, caller language for each outcome and an on-call owner. Expansion should wait for sign-off on unresolved critical scenarios, not just a smooth demonstration.

Write down edge cases before launch: ambiguous place names, multiple stops, changed pickup dates, poor audio, a caller who refuses a required field, a request crossing two teams and a carrier whose availability changes during the call. Run these cases through the exact prompt, integrations and queues used in production. They reveal where a fast answer could damage the capacity picture. Keep a rollback or pause control that disables new intake actions while preserving records for review.

Review quality and close the Agent Factory loop

Assign operations and sales owners to review a regular sample, with a named person responsible for resolving findings. Score caller classification, required fields, dates and units, promise language, handoff reason, capacity status and destination system. Review both successful and failed calls, including records that never reached a human. A useful audit asks whether the next operator could act from the record without listening again and whether the caller was told only what the system was allowed to confirm.

Define metrics before collecting them. Qualification completion can mean the share of eligible quote requests with every required field populated or explicitly marked unknown. Field completeness should show which required fields are present, while field accuracy should come from an audited comparison with the caller or approved system. Human handoff success should mean the intended queue or person accepted the request, not simply that a transfer was attempted. Time to human response should start when the task is created and end at the first recorded human action. Write-back success should exclude records that exist only in the voice platform. Duplicate rate, retry contact rate and human correction rate need the same clear denominator and time window.

Feed recurring errors into the prompt, field schema, routing rules, approved language and test set. Release one focused change at a time, compare it with the prior version and keep successful and failed examples. That review-and-improve cycle is the practical role of an Agent Factory: maintaining a workflow rather than a one-time script. A quality review process keeps decisions aligned with capacity operations.

Govern every release as an operational change

Give each release a version, owner, change reason and list of affected components: prompt, extraction schema, routing, approved phrases, integration mapping or retry policy. Test it against a fixed set of ordinary calls and edge cases before it reaches live traffic. Have the business owner review changes that alter what the agent may say, capture or write back. Deploy in a limited scope, compare the new version with the prior version, inspect early records and keep a rollback path. A release is not complete until the quality sample, exceptions and operator feedback have been reviewed. This makes Agent Factory governance concrete: changes are traceable, reversible and tied to observed workflow behavior.

Go-live checklist

• Define required, optional and explicitly unknown fields for each quote type.
• Test lane names, dates, time zones, units, accents and industry shorthand.
• Document what the agent may confirm and the exact triggers for human handoff.
• Map TMS and CRM fields, duplicate rules, failed-write-back alerts and ownership.
• Set lead, carrier, existing-load and urgent-request routes with named queue owners.
• Configure retry limits, opt-out behavior, business hours, after-hours rules and on-call transfers.
• Review pilot calls against accuracy, routing, capacity-status and promise-language criteria before expanding scope.
• Define metric denominators, audit ownership, release sign-off, version history and rollback criteria.
• Give an owner a dashboard, an exception queue and a way to pause the flow while issues are corrected.