In development · preparing pilots

FOR FORWARDING TEAMS AND OPERATIONS LEADS

Their vehicle.Your customer.

The customer wants an update, but the carrier and driver have the information. We are testing how to give the forwarder an agreed view of a subcontracted trip in a standalone web workspace.

Discuss a pilot The pilot process

Carrier and driver participation is agreed before onboarding.

Trip overviewILLUSTRATION

Recorded at 12:40

A gap in data

Trip A → BHired vehicle · Android

8 minposition age

Position age uses the recording time.

Interface illustration · sample data

WHEN THE CUSTOMER ASKS ABOUT A TRIP

You need an answer. First, you need the facts.

Hiring a carrier does not automatically grant access to their data. You need to agree who invites the driver, what information they share and who can see it. We start with one type of trip that can be tested together with the carrier.

The working question: what can we tell the customer now, and what still needs checking?

WHAT WE PROPOSE TO TEST

A view you can work with

01 /

Visibility with agreed access

Define the participants and information needed. The forwarder needs a clear view of the specific trip they are responsible for.

02 /

Facts for customer updates

Keep the last known position, its recording time and confirmed participant updates distinct. Information freshness should be visible.

03 /

History for a trip review

Review the recorded route after the trip. It helps reconstruct available facts; it does not establish liability on its own.

A supported Android phone
Agreed recipients
Clear sharing boundaries

DRIVER PARTICIPATION

Agree the process. Then connect the driver.

Before the pilot, we agree carrier participation, driver onboarding and access boundaries. The Android source needs a suitable device and the person's explicit participation in the work workflow.

The first workflow is worth discussing if…

You organise trips with different subcontracted carriers.
You need updates from hired vehicles to answer customer questions.
You can test a standalone workspace without a mandatory TMS integration.

A PILOT IN THREE STEPS

Start with one workflow

01
Choose one working question
Understand the updates your customer asks for and where information is missing today.
02
Agree with the participants
Choose a carrier, driver, device, information scope and recipients.
03
Test the repeat workflow
Review the first trip and the onboarding of another driver for the next one.

BOUNDARIES OF THE FIRST WORKFLOW

Test the essentials. Develop what comes next.

A pilot starts with agreed features on selected devices. Future capabilities are not automatically part of it.

Pilot foundation

Android, map and history

Agree on the device, recording, position freshness and available view. Test your particular workflow.

In development

A view for the customer

A limited, revocable link-based view. Readiness is confirmed before including it in a pilot.

Planned for release

Journal and notifications

Operational trip notes, events and Telegram notifications. Each workflow is confirmed separately.

Later stages

Tracker, geofences and ETA

One selected tracker model after validation. Geofences and automatic arrival prediction need separate testing.

BEFORE WE TALK

Questions about the pilot

Do we need another TMS?

The first workflow is a standalone web workspace for trip visibility. It does not replace order management or accounting in your TMS.

Can we use it from our TMS or ERP?

A ready-made integration has not been confirmed. Tell us if this is essential: it requires a separate integration workflow.

Can the customer see only their trip?

We are preparing a limited link-based view with revocable access. The specific workflow and information shown are confirmed before including it in a pilot.

Will it warn us about delays?

Automatic arrival prediction and geofences are planned for later stages. A working ETA or automatic delay warning is not currently promised.

Explore the details