Designing the core operations for a growing customer platform
A customer places an order. Somewhere in that moment, a satellite gets scheduled, a task drops into a queue, imagery gets checked for cloud cover and quality, and a dozen small judgment calls get made about whether it can be captured, and when, and by whom.
The customer never sees any of this. To them, the order is placed — the rest is Pixxel’s problem now.
But “Pixxel’s problem” was really several teams’ problems, each holding a different piece of it. Operations knew whether a satellite could actually make the pass. Customer Success knew whether the customer was still confident or starting to worry. Engineering knew what the system could tell them, and what it couldn’t.
None of them were looking at the same picture. Their answers lived in different spreadsheets, different tools, different Slack threads — and stitching them together, order by order, was work someone had to do by hand.
The customer saw one platform. Behind it, the teams supporting them saw fragments. Order Desk Admin started as an answer to a simple, uncomfortable question: if the front door was this clear, why was everything behind it still scattered?
The Bridge
Order Desk Admin became the operational layer behind Order Desk. It brought together the information teams needed to manage organizations, follow orders, monitor tasks, inspect imagery, understand changes, and support customers throughout the ordering journey.
The intention wasn’t to expose everything happening behind the scenes. It was to give the teams behind Order Desk the right context to understand what was happening and act on it.
The Start
Getting there wasn’t going to be simple.
Admin touched every team that kept Order Desk running — Operations, Engineering, Customer Success — and each of them had spent months living inside the gaps of how things actually worked. This wasn’t a small internal tool. It was the thing that had to hold the operational side of the business together.
- Operations
- Customer success
- Engineering
So we began the way most hard problems get untangled — by getting everyone into the same room to name what wasn’t working, and why.
The challenge? Building a platform that could carry that weight without becoming one more system for those same teams to learn.
Decoding the current scenario
We worked closely with Customer Success and the teams who supported orders day to day. Together we walked through real scenarios and mapped the spreadsheets, internal tools, data structures and hand-offs that kept the process running. We also talked to the teams who owned those systems to learn where the data came from and how it was kept up to date.
The deeper we went, the more scattered it looked. Organization details sat in one place and orders in another. Tasks ran on their own workflow. Image-level details took more digging, and when something was unclear, the answer usually sat with another team.
The information wasn’t missing. The connections were.
Once the pieces were mapped, we looked for a structure that could tie them together. Five core objects ran through the whole lifecycle:
Organization → Order → Task → Capture → Image
Compliance, payments, processing, delivery and support all run around these objects.
One question guided us throughout: what does a team need to know to make the next decision? That question became the foundation of the Admin experience.
That became the foundation for how we structured the Admin experience.
Making it central
The challenge wasn’t simply to centralize information. If we put everything into one place, we’d risk creating a different problem — too much information, not enough clarity. So we focused on giving teams enough depth to investigate, while keeping the experience clear enough to act on.
Put the organization in one place
An organization wasn’t just a customer record. It contained the context that shaped everything that happened next — configuration, contract and orders. Previously, managing this information could involve spreadsheets and backend dependencies. We brought it together into a single organization view, allowing Customer Success to understand the organization, make relevant changes, and immediately see the orders connected to it. The organization became the starting point for understanding the customer.
Manage all the tasks at one place
Tasks were also brought together. The tasks screen lets the team see progress across all work, adjust priorities, extend deadlines when needed, and review the captures linked to each task. This gives them a clear sense of what is on track and what needs attention, so they can answer customer questions with accurate, up-to-date information.
Assess all the image level status of the orders
As we followed the lifecycle deeper, we realized that an order-level status wasn’t always enough. The real question was often: Is the imagery actually usable?
We therefore designed visibility at the image level — showing capture time, cloud coverage, processing status, output quality, reprocessing requirements, and whether the captured strip covered the requested AOI.
The team could now understand the state of the imagery without waiting for another team to interpret it. More visibility meant fewer hand-offs.
The goal was simple: reduce the number of places people needed to look.
Making it clear
Centralizing information was only the beginning. The next challenge was helping people understand what had happened, what was happening, and what needed attention.
Make the journey traceable
When something went wrong, knowing the current state wasn’t always enough. We needed to understand how it got there.
The activity view brought the history of an order into one place — from its creation through parameter changes and subsequent updates.
Who changed it? What changed? When did it happen?
Instead of reconstructing the story through Slack messages or conversations with other teams, the order itself could tell the story. The history became part of the context.
Analyse all the activities taking place in each screen
While detailed screens helped answer specific questions, Customer Success also needed to understand what was happening across the system.
We introduced an Insights layer to provide that broader perspective.
Instead of moving through individual organizations, orders, tasks, and images, the team could step back and understand overall activity, identify patterns, and spot areas that needed attention.
The interface moved from showing information to helping the team interpret it.
Not every image needs to be captured
Some operational questions aren’t about what is happening. They’re about when.
A list of tasks could tell us what existed, but it didn’t easily show what was approaching, what was active, or where deadlines were beginning to overlap. We explored a timeline view that placed tasks against time, giving the team a visual understanding of ongoing and upcoming work.
What was once a long list became a clearer picture — what needs attention now, and what’s coming next.