When a freight company ships goods on a Lion Air plane, their staff book that shipment through a web portal built by Belli. Over six weeks in August and September 2026, eight changes to that portal cut the typical booking from about 4.5 minutes to 1.6, this is what changed, how it was tested, and the numbers behind each claim.
Where the time was going
Booking a shipment takes five steps: describe the cargo, pick a flight, enter the customer, attach documents, then review and submit. In mid-August, 13% of agents were spending an average of 31 minutes inside that flow per booking. Before any changes shipped, the team pulled two weeks of portal data (11,284 bookings by 315 agents) to see where the time went. Three things stood out.
Agents kept going backwards
The 89 agents averaging over seven minutes per booking returned to the cargo-details step 4.4 times per session on average. The data shows the revisits; it does not say why, so the team treated the cause as an open question rather than assuming one.
Problems showed up too late
Two checks, for a prepaid balance that was too low and for an account set up in the wrong currency, only ran at the final submit step, after the whole form was filled in. The currency problem surfaced only as a brief pop-up notification, which the team's own task list described as "silent". An agent copying a previous booking without a wallet in the right currency landed on a screen with no next action at all.
The frustration was measurable
28% of sessions from slow agents contained rage clicks, the same control pressed repeatedly in quick succession. Slow agents averaged 1.6 rage clicks per session; agents in the one-to-seven-minute range averaged 0.45.
The team's working estimate is that an agent handles 15 to 20 bookings a day, so a minute saved per booking is 15 to 20 minutes saved per agent per day. The target set at the outset was to bring both the average and the typical booking from about 5 minutes to 2.5.
What changes
Comparing the three weeks from 28 August to 15 September against the week of 16 to 22 September, the typical booking fell from about 3 minutes to about 1.6 minutes, a 47% reduction. This is the figure the analytics team itself marked as the defensible one for external use. The daily figures behind it are in the chart at the top of this article: 2.7 to 3.7 minutes a day in the first window, 1.5 to 1.8 minutes a day in the second, across between about 180 and 640 bookings a day.
Two notes on what this number is and is not. First, it is the median, the typical booking, not the average. Averages during the controlled test were 18 to 23 minutes, because a minority of sessions run very long: at day six, 17 to 19% of sessions exceeded 30 minutes. Second, the mid-August figure of about 4.5 minutes on the chart was recorded before the 28 August tracking changes and with no filtering of long sessions. It is shown for context, but the 47% is not calculated from it.
If the 1.6-minute saving on a typical booking held across an agent's 15 to 20 daily bookings, it would come to roughly 24 to 32 minutes a day per agent. That is an estimate from the medians, not a measured figure. The original target of 2.5 minutes, marked on the chart, was passed in the week of 16 September.
The two drops in that line coincide with releases: the first on 28 August, the second with a run of releases between 10 and 17 September. The 16 September cut-off is also where the measurement was tightened (sessions resumed from a saved draft were excluded, and a second portal address was added to the count). The analytics team estimates that tighter measurement accounts for 0.3 to 0.5 minutes of the 1.4-minute drop, with the remainder attributed to the product changes. The chart alone cannot separate the two, which is why the controlled test described later matters.
The lead chart counts every booking started from scratch. Two other kinds of booking were tracked separately once the events for them existed, and both moved the same way:
Copied bookings, the ones made by duplicating an earlier booking, took longer than fresh ones through early September (typical 3.7 minutes against 3.2) and then fell to about 1.6 minutes. Bookings on a route the agent had booked before tracked all new bookings almost exactly, before and after the September change.
Eleven changes, in the order they shipped
Each change below targets a place where agents got stuck, lost work, or found out too late that something was wrong. They are listed in the order they shipped. Not all of them were tested the same way; which were and which were not is explained after the list.
1. A way out when no prepaid wallet is set up (August 24)
Agents pay for bookings from a prepaid wallet held in a particular currency. Copying a previous booking is how about 37% of new bookings are made (weekly share 33.5 to 38.8% between 25 August and 27 September), so a dead end in that flow is hit often. Before this change, an agent who tried to copy a booking without a wallet in the right currency reached a screen with no next step. Now a dialog states the problem and links to the page where a wallet can be added.
2. Telling agents about problems at step two, not step five (August 26)
The two checks that used to run only at submit (balance too low, currency mismatch) now run as soon as the agent picks a flight, at step two of five. The dialog shows the shipment cost, the current balance, the minimum the account must keep, and the shortfall, with a button to top up. The currency mismatch, previously a small notification, became a dialog the agent has to act on.
3. Never losing a half-finished booking (August 28)
The portal now saves booking progress in the browser as the agent types. If the page is refreshed or closed before submit, the next visit offers to continue from the saved step, showing what was already filled in. In the first 57 hours this prompt appeared 36 times; about 60% of agents chose to start fresh rather than continue, which the team flagged for review.
4. Measuring properly (August 28)
Not a change agents can see, but the one everything else in this article depends on. Tracking was added for the route being booked (origin and destination), for copied bookings, for resumed drafts, and for the new dialogs. Before this, none of the dialogs reported when they appeared, and route-level comparisons were impossible because booking events carried no route.
5. Filling the form from the quote (September 10)
When a booking starts from a spot rate (a price already quoted for a specific shipment), the origin, destination, commodity and weight are filled in automatically rather than typed again.
6. Locking fields the quote already decided (September 13)
Fields whose values come from the spot rate are locked so they cannot be edited, which the analytics team described as removing decisions the agent does not need to make.
7. An assistant inside the form (September 14)
An AI assistant shows suggestions inline while the agent fills in the form.
8. Clicking Submit twice no longer creates two bookings (September 15)
Before this change, retrying a submission after a timeout or connection error could create a second copy of the same booking. Repeat submissions of the same booking are now recognised and ignored, so a retry is safe. No figure for how often this happened before the fix appears in the analysis.
9. Catching route mistakes before they are submitted (September 15)
If the origin and destination the agent typed do not match the flight they selected, the portal now flags it on the spot instead of accepting the booking. In the screenshot the agent has entered Ambon to Tokyo and the portal warns that this does not match the selected itinerary. A fix to how special handling codes (the codes that mark cargo such as live animals or perishables) are handled shipped in the same release.
10. Fixing multi-airline bookings that got stuck (September 16)
Shipments that connect across two airlines were stalling at the review step because of an error in how the second leg was displayed. The leg handling was corrected and these bookings complete end to end again.
11. Removing screens with no way forward (September 17)
A review of the booking flow found several states where an agent could reach a screen with no valid next action. Those were removed, and the affected steps now record when agents leave.
The quote page, where agents check prices before booking, was redesigned in the 24 to 28 August release. In the first 24 hours, agents on the new version viewed it 3.5 times each against 1.6 for agents on the old version, with about 25 agents in each group. That is a small, early sample and is reported here as a direction, not a result.
How these were tested
The early checks (change 2), the autosave (change 3) and the redesigned quote page shipped behind one on/off switch on 25 August and were tested as a package against the old version; that test is the next section. The wallet dialog (change 1) shipped the day before to all agents, and change 4 is tracking rather than a feature. The September changes (5 to 11) shipped after the switch was on for everyone, so their effect shows only in the before-and-after chart, not in a controlled comparison. There is no per-change uplift figure for any of them, and this article does not invent one.
Why we didn't just ship it
A before-and-after chart cannot tell you whether a change caused the improvement, or whether it helped some agents while hurting others. So the team ran a controlled test, and the first readout is the reason this section exists.
The setup
Agents were first grouped by their average booking time over the two weeks before launch: under one minute (20 agents), one to seven minutes (206 agents), or over seven (89 agents). Within each group, half were shown the new version and half kept the old one, starting on 25 August at 18:40 UTC. Grouping first, then splitting, meant the team could see whether slow agents specifically were being helped or hurt, instead of reading one blended average. Seven accounts that submit 10 to 49 bookings in a single sitting were excluded from all comparisons; the analysts classed their pattern as a workload issue rather than an interface one.
The rule for going wider
Agreed on 26 August: the new version moves from half of agents to three quarters, then to everyone, only after 48 hours in which both booking time and the count of errors are no worse than the old version.
Day one looked like a failure
After 24 hours (917 bookings on the new version, 1,036 on the old, batch accounts excluded), the new version was slower overall: average 23.0 minutes against 19.8, up 16%, and typical booking 6.9 minutes against 6.1. Split by group, the picture was different. Agents in the one-to-seven-minute group averaged 7.1 minutes on the new version against 11.9 on the old, 40% faster. Agents in the over-seven group averaged 25.0 against 21.4, 17% slower. Slow agents on the new version were also revisiting every one of the five steps 16 to 19% more often, and they logged 25 errors against 13. A uniform rise across all steps pointed to something interrupting the flow rather than a problem with any one step; the team's leading hypothesis was the new autosave prompt, which was not yet being tracked. The day-one report recommended keeping the new version on for the fast and typical groups and considering a pause for slow agents while the autosave prompt was investigated.
By day three the direction reversed
After 57 hours (1,288 bookings on the new version by 176 agents, 1,645 on the old by 235 agents), the new version was ahead on booking time at every percentile: typical booking 4.6 minutes against 5.2 (11% faster), average 18.1 against 19.1. One measure still pointed the other way: agents on the new version finished copied bookings 79.4% of the time against 86.9%. The one-to-seven-minute group, now with 203 and 220 bookings, averaged 6.1 minutes against 8.2 (26% faster) with a typical booking of 1.7 against 2.5 (32% faster). The over-seven group had closed most of its gap: 20.4 minutes against 20.8. Rage clicks per session were 0.61 on the new version against 0.73, a 16% drop, and errors were 9 against 10.
By day six it held
With 2,530 bookings on the new version and 3,221 on the old, and looking only at sessions under 30 minutes, the one-to-seven-minute group averaged 3.5 minutes against 4.5 (22% faster) across 368 and 393 bookings. The over-seven group was level at 6.9 minutes each, with a slightly smaller share of sessions over 30 minutes (19.1% against 20.4%). Of 70 routes with at least three bookings in each group, 43 were faster on the new version. Agents who started copying a previous booking finished it 79.1% of the time on the new version against 72.1% on the old, a reversal of the day-three reading.
Rollout
The new version went to three quarters of agents on 1 September and to everyone on 3 September. By then, on familiar routes, the slowest one-in-ten booking was 18.0 minutes on the new version against 18.8 on the old, across 2,730 and 2,219 bookings, and the gap in completed copies had widened to 8.8 percentage points.
The readouts behind the chart, with their sample sizes:
About the data
All figures come from PostHog analytics on the Lion Air cargo booking portal between 14 August and 22 September 2026, with the duplicate-booking share from a follow-up pull covering 25 August to 27 September. Booking time is measured from the first recorded step of the booking form to confirmed creation. Seven accounts that submit 10 to 49 bookings per session are excluded from every comparison. "Typical" means the median; averages are given where the source reports them.
The measurement changed twice. On 28 August, tracking for routes, copied bookings, resumed drafts and the new dialogs was added, and daily figures from then on exclude sessions over 30 minutes. On 16 September, sessions resumed from a saved draft were excluded and a second portal address was added. The headline 47% compares 28 August to 15 September against 16 to 22 September; the analytics team estimates that 0.3 to 0.5 minutes of the 1.4-minute drop is due to the stricter measurement rather than the product. The controlled test (26 to 31 August) is unaffected by the 16 September change. The daily-time-saved figure is an estimate from medians, not a measurement. No per-feature effect was measured: the first four changes shipped together, and the later seven shipped after the controlled test had ended.