Why We Built a Rocket Into Our Emails

On hectic days, bookings would regularly be missing by the evening – and later it was hard to figure out why. Not a crisis, but annoying.

I'm a developer on a project team, and I built a small tool to solve it. It's now used across the entire company – and shows how solutions like this come about with us.

The Problem: Good Data, But Not Good Enough

We work with clients under different billing models – some time-based, some fixed-price. In both cases, it's important that we accurately record our work effort – not for monitoring purposes, but to answer our own questions:

• Was this project worth it for us?
• Where did we miscalculate?
• Where are we performing particularly well?

For time-based projects, this works naturally – the bookings are the basis for invoicing, after all. For fixed-price projects, however, booking quality was often not at the level we would have liked. Not out of bad intention, but as a consequence of missing incentives and full days.

We deliberately don't have a hard booking quota. And we don't want one. But we still wanted clean numbers. This balancing act – data quality without a control mechanism – was the real starting point.

The Idea: A Look at Yesterday, Close Enough to Matter

We track our working hours in a dedicated tool and project time in the ticket system. Both work great on their own – but the data isn't directly related to each other. That's exactly where the blind spot lies: you can't see at a glance whether everything you worked on has actually been booked.

My thought was: an overview of the previous day would be perfect. Close enough to still remember, and still easy to correct. And low-key enough not to be annoying.

So I sat down and built something.

What the Tool Does

Daily – just for me.

Every morning, each team member receives an email with the status of the previous day – provided they worked that day. The email contains:

• Booking rate for the previous day (e.g. "90% recorded")
• Overview of booked hours by project
• A small playful comment ("Nice, keep it up!")

When the booking rate is on the lower side, it's usually easy to spot at a glance what was missed – and it can simply be added retrospectively.

To make clear that this isn't about monitoring, every email includes an explicit note that this daily report goes exclusively to that individual. Nobody else sees it.

And because space travel is always somewhere in our DNA, each email features a matching image: from a launching rocket for a good booking rate, all the way to a plane wreck on truly rough days. It's not meant seriously – it's the little wink that turns an obligatory task into a brief ritual.

Weekly – for the team.

Every Monday, each team member additionally receives a report for their own team:

• Aggregated booking rate for the team
• Overview of project distributions
• Billing context

The report stays within the team – neither management nor other teams see the numbers.

Here too: there's no "right" or "wrong." It's a shared overview. And in my team, it's completely normal for unusual bookings in the weekly view to prompt a quick conversation – not as an accusation, but because it's often the tip of another issue: a project running differently than expected, a billing type that doesn't fit, a ticket that turned out to be much bigger than it looked.

From Personal Project to Com­pany-Wide Tool

I built the tool for myself first. Quickly, on the side. When I presented it to the team, everyone wanted it. Shortly after, we showed it to the other teams – and now the whole company uses it.

Nobody worried it would eventually become a monitoring instrument. Instead, the tool struck a nerve: many colleagues had long been frustrated with their own unreliable bookings – and were glad to have something that helps them do better, without anyone looking over their shoulder.

Today we're very happy with our bookings overall. Not because anyone is being monitored, but because it was made easier for us to work cleanly.

What This Says About Us

What I actually find most interesting about this story isn't the tool itself. It's that it could unfold the way it did here at all.

With us, it's not the exception but more the rule: someone spots an impediment – a small friction in daily work, something that could run more smoothly – and just gets started. Sometimes that person builds it themselves, sometimes they find someone to help. For larger developments, we discuss the scope within the company and get sign-off on the framework – but the initiative almost always comes from the teams themselves.

Behind this is a deliberate mindset: we value quality, we celebrate innovation, and we reject control.

These three things belong together: good numbers don't come from pressure, but from helpful tools. Innovation doesn't emerge from quarterly targets, but from everyday work. Control makes work unpleasant – and ultimately makes the data worse.

The difference isn't in the tool. It's in the mindset behind it.