Guiding buyers and sellers through shipping, inside the chat
Order tracking used to live in a separate section. Shipping now happens in the conversation between buyer and seller, across two shipping flows and the requirements of five teams.
The case in 30 seconds
The challenge
Once the bike is paid for, the buyer is waiting for an item worth several thousand euros, sent by a stranger, often from another country. In between, there is a box to deliver, a bike to take apart and pack, a home pickup, a carrier and 48 hours to check everything. Until 2025, none of this happened in the conversation: tracking lived in a separate section, and to find out where their order was, people wrote to support.
The bet
Make the seller the buyer’s first point of contact, before support. To do so, bring shipping into the thread where they had already talked, and tell each of them, at every step, what comes next and who needs to act.
My role
As the only designer, working with a PM who coordinated the teams, I designed shipping in the chat end to end: two flows, their sub-flows and every message in them. Most of the work was turning the requirements of five teams, from logistics to claims, into a flow that two private individuals can follow without instructions. The project started on my initiative: I showed the first screens to my manager and the CTO, whose approval let me extend it to the whole flow.
The outcome
Every order has its thread. Since June 2025, every shipped order is tracked in the conversation, across both shipping flows.
Signals consistent with the bet. After launch, buyers and sellers mention the updates and the chat as what reassured them, and reviews left after an order mention support and tracking less often. These signals support the bet, but on their own they do not show that questions moved from support to the seller.
Role
Product Design Lead, buycycle
Reporting to
Co-founder, acting CPO
With
One PM, about ten engineers, five teams
Design team
One UX designer
Period
2024 – 2026
01 · The problem
Order tracking sat next to the conversation, not in it.
Buyer and seller had talked throughout the negotiation. Once the bike was paid for, they were sent somewhere else.
Before 2025, once payment was made, the order was tracked in a dedicated section: "Sale details" for the seller, "Order details" for the buyer, reachable from the profile or from the chat. It listed steps that became active as the order progressed. In the chat, all that remained was a banner, "Your bike is on its way. Follow the shipping status in your orders.", and two buttons: view the order, contact support.
The chat led to tracking, but the steps never appeared in the conversation.
The list of steps was not the problem. The separation was:
Nobody knew who had to act. The list showed where the order stood, not what the other side had to do. The buyer saw nothing of the packing, and the seller did not know whether the buyer had been informed.
Updates did not go through the conversation. A completed step left no trace in the thread. To keep the other side informed, you had to think of it, then check somewhere else.
Support answered instead of the seller. "Where is my bike?", "Has the box arrived?": questions the seller could answer in one sentence went to support. In autumn 2024, support received far more tickets each month than there were orders, across all topics.
02 · The bet
The seller first, support second.
The thread already existed. The order had to move into it.
The idea started from an intuition shaped by my work on the chat: the relationship built during the negotiation should be able to continue after payment. I first explored bringing tracking into the conversation on the buyer’s side. As I drew the first steps, two things became clear. The thread gave the journey continuity, before and after the purchase. And both sides had to be designed together: the buyer was waiting for news, but it was the seller’s actions that moved the shipment forward. I showed these first screens to my manager and to the CTO, and their agreement let me develop the approach across the whole flow.
My hypothesis was that if the steps and responsibilities were visible in the thread, buyer and seller would coordinate better, and the buyer would ask the seller the questions the seller can answer before asking support. At the moments that matter, the platform speaks in the format already set for the chat: the admin message, with a title, a short text and one action.
The same moment on both sides. At each step, the next action passes to the other side.
I finished the flows, edge cases and copy at the end of March 2025. Shipping in the chat was rolled out in early June 2025, all at once.
03 · After payment
Two flows, five teams, two private individuals.
What had to fit into a conversation thread.
One thread, two logistics setups: 56 admin messages in the two live flows. The registry’s 113 also cover the eight flows of the 2026 overhaul.
Five teams come into play at this point. Their requirements became the rules of the flow.
The constraintThe rule in the flow
Logistics
A badly packed bike costs up to €300 in carrier surcharges. If it is lost and there is no photo, no claim can be made.
No photos, no label.
Claims
Without a photo, damage cannot be attributed.
Photos serve as evidence, for both sides.
Customer support
Every ambiguous message turns into a ticket.
One action, two sentences. Everything else goes to the help centre.
Logistics backend
The logistics system decides every step.
Only facts move the order forward.
Engineering
Every message is a development task.
One message format for every case.
No team opposed the principle, and support even refined the copy using what it knew about recurring questions. But requests kept coming, and almost all of them were legitimate. I followed a simple rule: accept the request, not necessarily the form it came in. Three decisions show how: rebuilding a step, fitting a constraint in at the right moment, and letting the teams write the messages themselves.
Decision 01 · RebuildingRebuilding the packing step
Situation
Logistics wanted more detailed packing instructions, and the claims team needed photo evidence.
Choice
Instead of adding them to the existing step, rebuild the step so it could carry them.
Benefit
Sellers are guided step by step, and their photos protect them in a dispute.
Trade-off
A lot of effort asked of the seller, and as much friction before they get their shipping label.
In hindsight
Well-placed friction is sometimes welcome, especially when it guides people who want to do things right.
No photos, no label. One instruction, one photo, one step.
Packing decides the condition of the bike on arrival, and it is the one moment the buyer sees nothing. For logistics, a badly packed bike means a damaged bike and a carrier surcharge. For the claims team, it means a dispute with no evidence. The request was legitimate. But added as it was, it would have turned the step into a technical page, a list of instructions sellers scroll past without reading, rather than a flow that guides them.
I did not reject the request. I rejected adding it to the existing step, which no longer fitted. I rebuilt the step as a sequence, with an instruction and a photo at each stage of packing: the item unpacked, the item in the box, the box sealed. The shipping label unlocks only once the photos are provided. Logistics can put its detailed instructions there, the claims team gets its evidence, and the seller gains protection: in a dispute over damage they did not cause, their photos speak for them. The buyer can see the photos too.
This choice has a price. Taking a bike apart, packing it and photographing every stage before getting a label is a lot to ask of a private seller, and each instruction adds friction. Yet reviews left after an order showed me the other side of that friction. Sellers praise "clear and comprehensive instructions", step-by-step guidance that took them "through the entire process, from start to finish", and photo documentation that protects everyone involved. Many sincerely want to do things right, and were waiting to be told how.
Decision 02 · Fitting it inAsking for the pickup date at confirmation
Situation
To send the box out, logistics needs to know the pickup date.
Choice
Ask the seller for the date as soon as they confirm the sale, before the box has arrived.
Benefit
The buyer, who has already paid, waits no longer than necessary.
Trade-off
The seller picks a date before receiving the box, without knowing whether they will be ready.
In hindsight
The least bad option, as long as the box and the pickup have to be planned together. I would do it again, with rescheduling as a safety net.
Four screens to commit to a date, five to seven days ahead.
For a box to reach the seller in time and a carrier to show up on the right day, logistics has to plan everything at once. So the seller picks a date and a time slot as soon as they confirm the sale, five to seven days ahead: enough time for the box to arrive and for the seller to pack.
We considered the reverse: letting the seller choose the date when the box arrives, once they know they are ready. But the carrier also needs time to schedule the pickup. Postponing the choice meant making everyone wait longer, starting with the buyer, who had already paid.
That is why confirming the sale is a sub-flow in its own right: the address, the packaging, the pickup date and time slot, then a summary. The seller commits to a date knowing what it involves. Even the entry point matters: in September 2025, the "Confirm sale" button became "Confirm pick-up address and date", a label that says what the seller is about to do. In the following weeks, the confirmation rate for bike sales rose from 83% to 89%, although the effect of the label alone cannot be isolated.
The stakes are real: orders with at least two missed pickups end up cancelled or refunded in 22% of cases, against 6% for orders with no failed pickup. This association shows how much the problem matters, but it does not attribute those cancellations to choosing the date early. To limit the risk, the flow lets the seller reschedule the pickup, before the date or after a failed attempt, and the buyer is told in the thread each time.
Decision 03 · Opening upOpening admin messages to the teams
Situation
Every copy fix required an app release, while support and logistics wanted to make corrections quickly.
Choice
Move the copy out of the code and hand it to the teams, within a framework I built.
Benefit
A message that causes confusion can be fixed without waiting for an app update.
Trade-off
I no longer review every sentence, and a message can grow longer with each correction.
In hindsight
A principle only lasts if someone else keeps it alive. Support now owns it, and that handover, more than the registry itself, is what makes it last.
One source to write from, and rules for everyone.
At launch, the admin message copy lived in the app’s code. Fixing a sentence meant waiting for the next release. Support, which saw every day which message generated tickets, and logistics, which wanted to adjust an instruction as soon as a problem appeared, could not wait. In September 2025, logistics even wanted to ship a long list of instructions immediately and iterate afterwards.
The temptation was to keep control of every sentence. I did the opposite. Since February 2026, the copy has been served by the server, and the teams can change it without waiting for a release. But not without a framework. I built the message documentation from scratch: a registry of more than a hundred messages, each with its trigger, its text and its action, for both buyer and seller. The writing rules are set out there, and the support team now looks after it.
04 · What changed
What users say.
Reviews left after an order changed in tone.
Before June 2025, reviews left after an order asked for status updates:
"Users are dealing with valuable goods, so need to know more about the process and status involved."
A buyer, April 2025
"Had to contact support several times because things were not clear in the UI."
A seller, May 2025
Afterwards, they mention tracking as what reassured them:
"The site kept me notified every step of the way and it was great to be able to chat with the seller."
A buyer, October 2025
"The step-by-step instructions and regular status updates gave me complete peace of mind."
A seller, July 2026
These reviews also mention support and tracking less often, comparing February to May 2025 with July to December 2025:
Share of reviews that mention
Buyers
Sellers
Support
14% → 8%
16% → 10%
Tracking
9% → 6%
5% → 2%
The count relies on keywords, which do not distinguish a positive mention from a negative one. Support tickets point the same way. Before June 2025, “Where is my bike?” was the most common reason to contact support. Relative to orders, these tickets fell by more than 60% in the second half of 2025 and by three quarters by autumn 2026, while tickets overall halved. Packaging questions, which a message cannot resolve, stayed level throughout. Neither can be attributed to the chat alone, since other changes happened the same year, but the bet can be read in users’ own words.
The flow also held up as volume grew. Components and equipment overtook bikes in number of shipments in October 2025 without a redesign, and the photo step reached them in March 2026, modelled on the one for bikes.
05 · The limit
What a message cannot fix.
When logistics falters, the thread can report it, but not absorb it.
In spring 2026, a box shortage at the manufacturer made boxes take much longer to arrive. In the second quarter, many arrived after the scheduled pickup date, and packaging became the top reason to contact support. We added a warning at checkout and in the sale confirmation, and adapted the messages. The thread did what it could: tell the truth in time, and give everyone their next action. It could not make the boxes arrive. In reviews left after an order at that time, one seller in three mentioned the box.
Missed pickups fall under the same limit. They have many causes: a seller who is not ready, a carrier who does not show up, a box that arrived too late. The flow can remind people of a date, inform the buyer and offer to reschedule, but it cannot resolve transport incidents on its own.
These limits fed into the 2026 overhaul: eight shipping flows instead of two, depending on whether the item is picked up from home or dropped at a parcel point, delivered to the door or to a parcel point, and packed in a buycycle box or not. It is not yet fully in production, so its effect for users has yet to be measured, and it deserves its own case once it has proved itself.
06 · Making the system readable
A reference site for the people building it.
Eight flows and dozens of messages: the team had to find its way without me.
To prepare this overhaul, I created a reference site for the engineering team. It brings together the eight flows, the admin message registry, the mapping between each step and what buyer and seller see, verification criteria, and complete prototypes of every variant of the sale confirmation and the packing step.
One step, from spec to prototype to acceptance criteria.
Engineers mainly use it for three things: the step mapping, the variant prototypes and the registry. Its value does not depend on the overhaul succeeding: it means the flow can be read, built and checked without going through me.
07 · Open questions
Two tensions, neither resolved.
Two questions the flow does not yet settle.
How much logistics to show the buyer. The buyer takes no part in packing, yet that is where the condition of their bike is decided. The photos show them some of the stages, but showing every move the seller makes also invites them to worry about each one. Where does useful transparency end?
Keeping the principles without reviewing every message. The registry sets the rules, but each team can now add its own sentence. How do we notice that a message is drifting before the tickets tell us?