REQUEST
Define the work
HOW SIGNAL WORKS
One delivery request.
A clear path through the work.
Tell Signal what needs to move. The request becomes structured delivery context, the requirements are reviewed, the execution path is coordinated, progress stays connected, and the completed result returns to the same record.
01REQUESTWork described
02REVIEWRequirements checked
03FULFILLMENTExecution path
04EXECUTIONField work
05PROGRESSStatus connected
06EXCEPTIONSChanges owned
07COMPLETIONResult documented
08PROOF + HISTORYEvidence retained
01 / REQUEST
Describe the work, not just the addresses.
A usable business delivery request explains both ends of the handoff and what moves between them. Origin, destination, shipment, timing, handling, receiving, access and proof expectations give Signal and the people carrying out the work a common operating reference.
A street address alone cannot explain a ready window, loading condition, receiving contact, site restriction or special handling need. Capturing those details early gives review and field execution a better foundation, especially when several teams participate in the handoff.
Requests may begin in Customer Portal through structured entry, a plain-language description or supported source documents where available. The goal is less repetitive entry while keeping the customer in control of review.
Explore the Customer Portal →ORIGIN CONTEXT
Define where the work begins.
Pickup readiness, release contacts and access conditions shape the operating plan before movement begins.
02 / REVIEW
Know what the request requires before committing the work.
A prepared request is not automatically accepted work. Signal reviews route and timing, shipment details, operating requirements, service and equipment needs, receiving conditions and program context before an execution response is established.
The review asks practical operating questions. Can the requested window support the route? Does the shipment introduce a handling or equipment need? Are origin and receiving conditions understood? Does the customer expect completion evidence that must be carried into the plan?
Clarification is a valid outcome. Missing access instructions, uncertain handling needs or incompatible timing can require another customer conversation before the request is ready to plan.
ROUTE + TIMINGSHIPMENTREQUIREMENTSSERVICE + EQUIPMENT
SIGNALREVIEW
NEEDS CLARIFICATIONREADY TO PLAN
GEOGRAPHYVEHICLEHANDLINGTIMINGSERVICE
SIGNALREQUESTDelivery ProfessionalCarrierSpecialized ProviderPartner / Fleet Capacity
FIELD EXECUTION
Direct field work with the request context attached.
A delivery professional may fit work that depends on clear pickup, handling, destination, and handoff instructions.
03 / FULFILLMENT
Connect the right execution path to the requirements.
Signal is coordinating more than two coordinates. Geography, timing, shipment, handling, equipment, service, destination conditions and proof expectations shape the delivery response appropriate to the work.
Depending on the request and program, execution may involve a delivery professional, carrier, specialized provider or partner capacity. The relevant pickup, shipment, destination and completion context follows the selected path without exposing internal ranking or commercial logic.
The field team needs enough context to perform the work responsibly: what is ready, where the handoff occurs, which instructions matter and how completion should be documented. Availability remains specific to the request, program and operating conditions.
Meet the Signal network →Delivery professionals →
04 / EXECUTION
Carry the work through pickup, movement, and handoff.
The delivery professional or provider receives the pickup, shipment, handling and receiving context needed for the field work. Signal keeps instructions, communication, available progress and the handoff result tied to the request.
LocationTimingShipmentHandling
/ PROVIDER
InstructionsCommunicationRelevant updates
AccessReceiving instructionsProof requirements
05 / PROGRESS
Keep the request connected while the work moves.
Assignment and field execution do not replace the original request. The route, shipment, requirements, contacts and completion expectations remain available as the operating state changes. Supported progress can return to the customer view while private dispatch and provider information remains bounded.
MATERIAL STATUSOPERATING UPDATESSIGNAL REQUEST RECORD
06 / EXCEPTIONS
When the plan changes, give the change an owner.
Receiving access, timing, destination instructions and field conditions can change. A change should not erase the original request or disappear into a message thread. It becomes part of the record and receives review, ownership and a next action.
Some changes can be incorporated as updated operating context. Others need customer input, a receiving decision or an operating response before the delivery proceeds. Signal keeps the interruption visible without pretending that every issue can be resolved by software.
Technology keeps the work connected. People remain responsible for the decisions that require judgment.
OPERATING TRACE / NORMAL
NORMAL PATH
The operating path continues.
The delivery advances through the example lifecycle with the original request context still attached.
07 / COMPLETION
Return the documented result to the record that started the work.
A completion record answers several different questions: what result was recorded, where the handoff occurred, which evidence is available and how the delivery progressed. Those perspectives belong to one delivery record rather than four disconnected summaries.
The exact evidence depends on the request, service and program. Signal preserves the customer-appropriate result while supporting review when a completion detail needs clarification.
DELIVERY RESULT
What happened?
01Completion recorded02Result available03Request retained
DELIVERY RESULT
What happened?
The completion state and customer-appropriate result remain tied to the delivery record.
08 / PROOF + HISTORY
Keep evidence and lifecycle history attached.
Proof is not a detached artifact. Available completion evidence belongs with the delivery request, relevant stop and request history. That association helps customers review what happened without rebuilding the handoff from separate emails and files.
CONNECTED RECORD
One request. One connected history.
The operating path can involve different people, systems, providers, locations and conditions. Signal keeps the request, requirements, fulfillment context, progress, exceptions, proof and history attached as those contributors and conditions change.
The record accumulates rather than restarting at every handoff. Review can refer back to the submitted need. Execution can carry forward the accepted instructions. Exception handling can preserve both the earlier condition and the current direction. Completion can return evidence to the same history.
Supported customer workflows and integrations can receive and return authorized delivery context without turning the delivery into disconnected records. Explore API & Integrations →
FOUNDATION / 01SIGNAL REQUEST RECORDOriginal request remains connected
ORIGINAL REQUESTRequirements · Locations · Shipment · Schedule
FULFILLMENTExecution approach · Relevant fulfillment context
PROGRESSDelivery events · Available status
EXCEPTIONSChanges · Decisions · Ownership
COMPLETIONDocumented result
PROOF + HISTORYAvailable evidence · Retained lifecycle history
DIFFERENT PROGRAMS / ONE FOUNDATION
The operating path adapts to the delivery.
The program describes how the delivery work is organized. Services describe what the job requires. Equipment describes what may be needed to execute it. Availability and the final operating approach depend on the request and market.
01
SERVICES & EQUIPMENTExplore what the job may require →Same-Day Delivery
Timing, rapid review, local capacity and completion evidence.
02Scheduled Delivery
Planned timing, receiving windows and repeatable requirements.
03Dedicated Delivery
Program continuity, consistent operating context and ongoing review.
04Final-Mile Delivery
Destination conditions, access, handling, receiving and proof.
05Route-Based Delivery
Stops, sequencing, service windows and route-level progress.
06Inter-Branch Transfers
Origin and receiving branches, continuity and handoff confirmation.
07Distribution Logistics
Movement stages, intermediate locations and continuity by leg.
08Warehousing & Storage
Inbound context, storage requirements and onward movement.
HOW SIGNAL WORKS FAQ
Practical questions about the operating model.
What happens after I submit a delivery request?
Signal reviews the delivery context, including route, shipment, timing, requirements and receiving conditions. A prepared request begins the review; it does not by itself confirm that work has been accepted.
Does every request follow exactly the same process?
No. The eight-stage model is the common operating foundation. The detailed review, execution path, visibility and completion requirements depend on the delivery and program.
When is a request confirmed?
Confirmation occurs through the applicable quote or ordering workflow after the necessary request context has been reviewed. Preparing information on the website is not an accepted order.
How does Signal determine the delivery approach?
Signal reviews geography, timing, shipment, handling, service, equipment, receiving and proof needs. Those conditions inform the execution model that is appropriate for the request.
What information should I provide?
Provide origin and destination details, requested timing, shipment information, contacts, access conditions, handling needs and any completion or proof expectations that affect the work.
How are delivery professionals or providers selected?
Signal coordinates with an appropriate execution source based on the request and program. That may involve a delivery professional, carrier, specialized provider or partner capacity. Availability is request-specific.
Can Signal support scheduled or recurring work?
Signal can review scheduled, route-based, dedicated and other recurring operating patterns. Each program still needs clear stop, timing, service and receiving context.
What happens if delivery requirements change?
A changed instruction or operating condition becomes part of the delivery record. Signal reviews what changed, who needs to act and which current instruction should carry forward.
How are delivery exceptions handled?
Exceptions remain visible for ownership and review. Technology keeps the issue attached to the request; people remain responsible for decisions that require judgment.
What delivery progress can customers see?
Customer visibility depends on the program and supported workflow. Relevant progress and attention states can remain tied to the request without exposing private operational information.
What proof is available after completion?
Available completion evidence depends on the request, service and program. Where supported, proof remains associated with the appropriate delivery and stop for later review.
What information reaches the delivery professional or provider?
The execution source receives the context needed to perform the work, which may include pickup, shipment, handling, destination, timing and completion requirements. Customer-sensitive and internal operating information remains bounded to the appropriate workflow.
Can Signal support specialized delivery requirements?
Signal can review white-glove, handling, equipment, site-access and other service requirements when they are included with the request. Support depends on the delivery, market, program and available execution resources.
Can Signal connect with our existing systems?
Supported customer workflows and integrations can provide or receive authorized delivery context. The connection method depends on the program and implementation. The API and Integrations page explains that product direction without changing the operating stages described here.
Does a market listing guarantee availability?
No. Market and program pages describe areas and operating patterns Signal can review. Service, equipment, timing and capacity remain specific to the request.
How do Customer Portal and integrations fit?
Customer Portal is Signal's first-party customer experience. Supported integrations can receive or return authorized delivery context. Both connect to the same broader operating model described here.
START WITH THE REQUEST
Give Signal the delivery.
Keep the context connected.
From a single urgent request to a recurring delivery program, Signal keeps requirements, execution, progress, exceptions and proof connected through one accountable operating path.