The idea was born at a conference: while one speaker talked about automations built in a month, leaders from InPost and Office Samurai joked they could do it in a week. “Why not 24 hours?” – someone said. For months, it was an inside joke until both companies decided to make it real and teamed up for a bold 24-hour automation experiment.
Results? Read along.
The Challenge
The first rule of SpeedRun was: the process to be automated had to be real. Setting up a dummy challenge would feel like cheating – automation only matters when it addresses actual company needs. Business Analysts prepared “must-do” and “nice-to-have” test cases to make the success criteria measurable.
The process selected wasn’t a routine task – it involved reading and extracting data from scanned documents. That meant handling unstructured input, occasionally even handwriting and scenarios where accuracy was non-negotiable.
What began as a playful conference joke soon became a serious project. The deeper we went into planning, the more we realized how complex the chosen process was, and the idea of delivering full automation within 24 hours started to look unthinkable.
Going back was not an option, though. Both companies assembled their best professionals and dived into preparations. Two Business Analysts were given the opportunity to review the process in advance to assess project feasibility, but shared no information with the SpeedRun Team before the event. Like in a standard project – initial analysis is when specialists see the process for the very first time.
Three InPost developers, three Office Samurai developers, and two InPost subject matter experts (SMEs) entered the SpeedRun arena with no prior knowledge of what they’d be automating. Only when the 24-hour clock started ticking did the full scope of the challenge reveal itself.
Ready, Set, Go!
The timer started at 2 pm, and so it began. The team spent the first two hours interviewing SMEs and carefully analyzing the process. A large on-wall whiteboard became a canvas for solution design and critical notes. Energy and determination were high, but first hurdles started to appear – like discovering that one of the email addresses in scope wasn’t a shared mailbox but a group, creating a significant technical challenge. The scope of the task began to feel overwhelming.
Analysis stretched and significantly depleted the precious time budget. At this point, the business analysts (BAs) were allowed to step in, give some hints and monitor if the main process flow is not getting sidetracked with less significant details. Wheels gained traction again. The team identified that the end-to-end process could be divided into two major parts, so they split it into two self-organizing squads where each person took on a specific role.
Each squad assigned one person to documentation (primarily creating a process map), another to coding a Dispatcher robot (responsible for preparing a queue of tasks), and a third to developing a Performer robot (executing the actual process in systems and applications). Additionally, one squad member focused on building the essential AI components – the “brain” of the whole solution: UiPath Document Understanding™ for reading scanned documents and generative AI (OpenAI’s ChatGPT) for semantic conversion of required values.
In total, the team had to develop five robots, each designed to work both independently and collaboratively to execute real test cases.
Marathon of the middle
As night fell, the coding phase brought a sense of stability. With clear individual goals and smooth squad cooperation, the team found their rhythm. Each squad consisted of three people, so they naturally became ‘Trios’. Both Trios sat in a short distance from another – close enough to collaborate instantly but far enough to maintain focus.
If I were to name the single most important highlight of the event, it would be this: frictionless cooperation.
Imagine a project where every blocker, question, or decision is resolved immediately, face-to-face. No waiting for replies, no distractions – just pure focus where everybody understands the assignment, the process and the technology. While these were unique circumstances, it was the most efficient project delivery I’ve ever witnessed.
But, of course, there were some problems along the way.
The complexity of the process was heavily underestimated. What seemed manageable during pre-event analysis turned out to be riddled with exceptions and nuances. The team’s ambition to handle every case properly had to be tempered. With time running out, they had to focus on ensuring the main process flow worked end-to-end.
And then, there was fatigue. It wasn’t about conditions – the facility provided everything: delicious catering, break rooms with sleeping mats, all the coffee you could possibly drink and medical support for emergencies (thankfully unused) – it’s just unnatural to stay up that long. The biggest crisis hit around 3 am. Development reached a tricky point and the team scattered – some seeking a brief shuteye, others pushing through.
Night is the darkest just before dawn.
Phoenix from the ashes
The turning point came with the rising sun, around 5 in the morning. It may sound overly poetic, call it what you will, but it truly felt like the team caught their second wind after a long stretch of sea-like silence.
By this time, the first versions of the robots were functional enough to begin unit testing. Documentation drafts were in place, and the Squads re-intensified cooperation to slowly start integrating the individual components into a cohesive solution. Despite limited training examples, the Document Understanding model successfully extracted data and the morning light really seemed to make a difference. The hunt for real test cases began. I wish we were wearing pajamas and bunny flip-flops to match the vibe.
Story aside, let’s not forget the complexity of the problem and the solution.
The first major part had to deal with emails and with scanned documents. Text was manageable, but for scans UiPath Document Understanding had to do the heavy lifting. Extracted values couldn’t be used raw, so ChatGPT stepped in to handle fuzzy-logic matching for details like addresses or dates – not so easy given the complexities of Polish declension.
The second part was even trickier. Data from the first stage had to wait for the arrival of follow-up documents containing additional input. Scans were pushed to (you guessed it) Document Understanding, threads had to be matched, items updated and only then did the final Performer bot execute the required actions.
This would have been a challenging project even with weeks to complete it. But no one gave up. The team pushed through until the very last minute, determined to deliver. Here’s a picture to prove it – this all started at 2 pm on Friday.
Time’s up!
The countdown stopped. We got a 10-minute breather before gathering in a conference room for test runs and final summary. Despite exhaustion, everyone seemed to be genuinely happy and surprisingly calm about the outcome. In the end, it wasn’t just about the results – what mattered most was living through the unique experience together. But cutting to the chase…
It worked.
Ten real, not-fabricated test emails went through the whole flow and returned the expected outcome, logged into a SharePoint spreadsheet. Given the known vulnerabilities in certain places, we were pleasantly surprised that the cases ran completely error-free. The committee, composed of representatives from InPost, Office Samurai, and UiPath, declared the project a success and it honestly felt like a tangible result, not an empty slogan.
To slightly balance the sweetness, only “must-do” functionalities were developed and the code required some optimization after the event. For instance, both the ‘Dispatcher’ and ‘Performer’ bot pairs were merged into single units. However, this doesn’t diminish the fact that InPost gained working, production-level automation in record time. The team completed an extremely difficult and exhausting challenge, showcasing an unmatched example of cooperation. The initiative and format of the event itself were a pioneering undertaking in the automation industry, which may be repeated (spoiler alert) or inspire others to follow suit. We strongly encourage you to experiment, challenge your daily business, and have some fun along the way.
The solution built during SpeedRun is working efficiently to this day. So far, it has processed 13,875 cases with only 534 business exceptions thrown (data from 05.04.2024 – 30.07.2025). With an average processing time of 6.19 minutes, it has already saved around 1.3 FTEs monthly. Except for the robots merge, the solution experienced only minor adjustments: small changes in reply to templates, dates and names conversions or storing attachments on SharePoint. The core architecture developed during the event still stands.
What’s more, the SpeedRun success inspired the InPost Team to keep up the momentum and half a year later the same architecture has been re-created to automate a very similar process which also continues to bring benefits to the company (over 9,000 successful runs).
Would you do it again?
If you need a simple answer, then yes, I would (me personally). But what I truly wish for is the chance to experience such fantastic working conditions more often. I’m not talking about working 24 hours straight – that was a one-time stunt dictated by the event format. What I would gladly repeat is the team spirit, the intense focus and the fun. These were unique circumstances, difficult to sustain or replicate often, but showed us just how incredible people can be.
