How Pakoline works

The order from request to review

Every step in order: who takes it, and what happens to the cargo meanwhile.

The request

The client describes the route, the cargo, the dates and the services needed: tail lift, helpers, refrigeration, waiting time. A request can be saved as a draft and finished later. Until it is published, nobody else sees it.

Carriers see the request

A published request appears on the load board. Cities, country, cargo, dates and budget are visible there — the street address and the phone number are not. At the same time the platform compares the request with carriers' trips on its own: the detour, the free capacity in the vehicle, the fit of dates and direction, the requirements for the vehicle. Both sides get the matches.

A carrier opens the request

To answer, the carrier opens the request — this costs nothing today. Only then do the exact addresses, the access notes and restrictions, and the names and phone numbers of the client and the recipient become visible. Before that the server does not send those fields at all — they are not merely hidden on screen.

Offer and negotiation

The carrier names a price, a currency, a pickup time and terms. The client can answer and the carrier can send a new revision: the offer keeps the whole chain of edits. A revision may carry a deadline; once it passes, the revision lapses on its own and can no longer be accepted.

The client picks a carrier

The list of offers shows the price, the timing, the terms, the carrier's photo and their rating from published reviews. The client accepts one. Every other offer turns into a rejected one at the same instant — an order cannot be accepted twice.

The agreement

At the moment of acceptance the platform assembles the agreement and stores it whole: route and cities, pickup date and delivery deadline, category, description, weight and volume of the cargo, the services ordered, the amount and currency, the terms and the validity of the offer, the revision number. The record carries a fingerprint, so it is visible that the text was not rewritten later. A term can be changed only by a change request that the other side has to accept; the price cannot go that way — it needs a new revision of the offer.

Loading

The carrier arrives, photographs the cargo and sends the picture to the client. The client looks at the photo and confirms having seen it — only then does the pickup code open up. The client tells the code to the driver, the driver enters it. The order moves to cargo on board, the trip begins, and live tracking opens for the client.

On the road

The client sees the vehicle on the map, the expected arrival time and the journal of the trip: the start, the stops, signal lost and signal restored. Gaps in the record are drawn as a dashed line instead of being guessed into a solid one. Questions are settled in the order conversation.

Delivery

At the drop-off the driver asks for the delivery code. That code opens up for the client only after the cargo has been picked up — earlier it does not exist for anyone. The driver enters the code and attaches a photo of the unloading. The order becomes delivered, tracking switches off, and every guest link to the map dies in the same second.

Closing and reviews

The client closes the order. Both sides are invited to rate each other: the carrier on punctuality, care for the cargo, communication and how well the vehicle matched; the client on the accuracy of the cargo description, readiness for loading, communication and keeping to what was agreed. A review cannot be left forever: the window after the order closes is limited, and the platform sets its length. Until the other side has written theirs, both reviews stay hidden — but only to the end of a limited waiting period; that way a rating does not depend on who wrote first.

Who is who

Four roles. Each has its own entrance and its own set of rights.

Client

The client publishes the request, picks the carrier, confirms loading with a code, follows the vehicle and closes the order. Only the client opens a dispute after delivery, and only the client issues guest links to the map.

Carrier

The carrier opens requests, sends offers, runs trips and assigns orders to them. The carrier also answers for the vehicle and for the driver having a device that reports its position.

Dispatcher

A dispatcher acts for a client or for a carrier under a representation contract. The contract lists the rights one by one: read orders, see offers, write in the conversation under their own name, open available requests, prepare offers, accept an offer on the client's behalf. What the contract does not list, the dispatcher cannot do. A contract can be paused or withdrawn.

Driver

A driver does not create an account with a password. The carrier hands out a seat code, the code binds to the first phone that used it and works on no other. A lost phone is answered by revoking the seat and issuing a new code. In the app the driver sees their trip and stops, and enters the confirmation codes.

What is hidden, and until when

A request on the board and a request in progress are two different amounts of data.

What everyone sees

Cities and countries, the category and description of the cargo, weight and volume, dates, the services needed and the budget. That is enough to decide whether you take the job.

What is closed

The exact pickup and drop-off addresses, the coordinates, the access notes and on-site restrictions, the client's surname, phone and email, the recipient's name and phone. While the request has not been opened, the server does not send those fields: they are absent from the answer rather than covered up with styles.

Why it works this way

An address and a phone number are what takes a deal off the platform and what gets abused most often. They are seen by whoever actually takes the job: the carrier who opened the request, and the carrier who was chosen. In the order conversation phone numbers and email addresses are replaced with a marker — terms belong where a trace of them remains.

Confirmation codes

Two short codes are the main protection for both sides. Without them it is one person's word against another's.

The pickup code

It is issued the moment the client accepts an offer. The client does not see it right away: first the carrier sends a photo of the cargo on site, the client looks at it and confirms. The code is spoken by the client to the person standing in front of them with a vehicle. A correct code means the cargo was taken by this carrier, and by the one who was agreed upon.

The delivery code

It appears only after a confirmed pickup — before that it does not exist. It is spoken by whoever accepts the cargo at the drop-off. Until the code is entered, the order does not count as delivered.

Why the code is not shown in advance

A code shown in advance stops being proof: it can be read out over the phone by someone who sees neither the vehicle nor the cargo. So each code opens up exactly when it is needed. The number of attempts is limited, the code has a lifetime and lapses when it runs out. If a code reached the wrong person, the client issues a new one and the old one stops working at once.

When there is nobody to say the code

It happens that nobody is at the drop-off, or the person cannot say the code. The driver then sends a request to confirm without a code: with a photo and a point taken on the spot, which is checked against the vehicle's last recorded position. That request goes to the platform for review, and the client is notified straight away. A driver cannot close an order on their own.

Tracking on the road

The map shows a vehicle, not a person, and it lives exactly as long as the order does.

What the client sees

The position of the vehicle, how fresh the last report is, the expected arrival time, their own part of the route and the journal of the trip. Other stops on the same trip are not shown: only how many of them come before your own event. The precision of the point is coarsened on purpose.

From which moment

The client chooses this in the request: either tracking starts after loading only, or also on the approach to the pickup point. After loading is the default.

A link for the recipient

The client can issue a guest link — for the person meeting the cargo, say. It shows the vehicle moving and the city of the next event, but not the address, not the coordinates of the stop, not the carrier's phone number and not the confirmation codes. A link lives no longer than one day, and it closes as soon as the cargo is delivered — no other lifetime can be chosen on screen. The link can be withdrawn at any moment, and it is closed to search engines.

When access dies

At the moment delivery is confirmed. Access to the map closes and every guest link of that order is withdrawn right there. Separately, a link dies when its own time runs out, and an abandoned tracking record closes itself if the driver's phone has been silent for too long.

The conversation inside the order

The talking happens where the order lies, not in an outside messenger.

When it appears

The conversation opens the moment the client accepts an offer, and it ties exactly two people: the client and the chosen carrier. Before that there is no private channel between them.

Why inside the order

Everything agreed along the way stays next to the order: with its time, its author and its attachments. If it comes to a dispute, it will be judged by this conversation and not by somebody's screenshots. A messenger keeps no such history, and it cannot be restored afterwards.

Phone numbers and email

Phone numbers and email addresses in messages are replaced with a marker. This is not a matter of manners: taking the talk outside leaves both sides without a trace, without a confirmation code and without a way to complain.

Document verification

Verification is not required to look around the platform, but without it the main things are out of reach.

What is checked

A confirmed email, a phone number, an identity document from both sides and a photo of the face. A carrier also submits a driving licence and a vehicle registration bound to a particular vehicle with a plate number. A document whose validity has run out is not accepted for review.

What it gives

Without passing it a carrier cannot start a trip with live tracking: the platform asks for a confirmed email, a phone number, a passed check and a vehicle with a plate. Which means cargo does not travel with someone nobody has checked.

Who looks at it

The documents are read by a person on the platform's side. They can accept them, reject them or ask for more. The files sit in closed storage and are checked for harmful content before anyone opens them.

Money

In short: the platform is not built into the settlement.

What the platform takes

Nothing. Publishing a request, a carrier opening a request, offers, the agreement and dispatcher contracts carry no charge today. The platform is supported by clearly labelled advertising and partner placements.

How the price is fixed

The amount and the currency are written into the agreement at the moment the client accepts the offer, and they fall under the fingerprint together with the other terms. The price cannot be moved by a change request — only by a new revision of the offer, which the client accepts again.

Who pays whom

The client and the carrier settle between themselves on the terms written into the agreement. The platform neither holds nor transfers the money. A dispatcher may charge for their own work — you agree those terms with them directly.

Disputes

A dispute is not a complaint into the void but a review with a named person on it.

Who opens it and when

A dispute is opened by the client after delivery, within three days. From then on the order can neither be closed nor carried on the usual way until the dispute has been reviewed.

How the review goes

Both sides write their account and attach evidence — photographs and documents. Everything lands in one dispute feed in order of time. The platform assigns an arbiter.

What the sides see

The sides see the whole feed except the internal notes of those reviewing it: only the arbiter and the administrator see those. Both sides are notified of every action taken by the other.

How it ends

The arbiter issues a decision with its reasoning, it lands in the dispute feed, and both sides are notified. After that the order is closed.

When something goes wrong

The common cases and what to do about them.

The order has to be cancelled

While no carrier has been chosen, the client cancels the request in one step. After an offer has been accepted, a cancellation must carry a written reason, and the other side is notified at once. Once the cargo is on board there is no cancellation — that is a review, not a button.

The offer stopped being valid

A revision has a deadline; after it the revision cannot be accepted, and both sides see the same thing. The carrier sends a new revision — the chain of edits is kept.

The carrier is not answering

Write in the order conversation: a trace with a timestamp stays there. If there is no answer, write to support — a request can be sent without signing in as well.

The code does not work

The number of attempts is limited, and once they run out the code is locked — that is protection against guessing. The client issues a new code and the old one stops working at that moment. An expired code will not work either: a code's lifetime is limited.