Overview
Closing a Storebox location affects much more than the physical site. Active customers may need to relocate or terminate their contracts, communication must happen at the right time, billing may need to change, and several internal teams need visibility into what has already happened and what still requires action.
The existing process relied heavily on manual coordination across teams and systems, which made it slow, difficult to track and vulnerable to errors. A single closure could take days to work through.
My role was to help turn that fragmented process into a structured product workflow with clearer rules, automation and operational visibility.
How it works
Before
Manual coordination across Customer Service, Operations, CRM, booking and billing.
After
- Affected bookings identified
- Internal visibility created
- Customer communication triggered according to closure timeline
- Relocation or termination workflow
- Billing adjusted where required
- Operational follow-up and case completion
Conceptual illustration, not a real system map.
My role
My role was to map the end-to-end process, identify where manual coordination and unclear ownership created risk, and translate the future process into product requirements, business rules and implementation priorities.
- Process mapping
- Business-rule definition
- Requirements and acceptance criteria
- Customer communication logic
- Relocation and termination workflows
- Billing and prorated-invoice behaviour
- CRM / Salesforce workflow
- Internal visibility and follow-up
- Cross-functional stakeholder alignment
- QA and rollout coordination
- Process documentation and workshops
- Senior-management communication
How I approached it
Understand the full process before automating it
The process crossed several teams and systems, so individual features couldn’t be designed in isolation. I mapped what happens to the booking, the customer, the contract and billing, what internal teams need to know, and which events trigger the next step.
Reduce repetitive manual work where possible
An admin booking can now be created directly from the existing booking context with the relevant information pre-filled. Booking-level visibility shows when a customer is affected by a closure. Communication timing is calculated relative to the relevant closure date. Each removes repetitive work and the need to cross-check information by hand.
Prioritise around customer and operational risk
Customer communication, relocation or termination, and correct billing carry far more risk than lower-priority edge cases or refinements. That ranking became essential once the scope grew.
When the scope grew
During implementation, additional locations were added to the closure programme, increasing both scope and urgency. Trying to deliver every planned scenario at once would have put the most important workflows at risk.
I reassessed the scope, identified the processes with the highest customer and operational impact, and aligned stakeholders around a revised delivery plan.
- Reassessed scope and dependencies
- Identified the highest-risk workflows
- Protected critical customer and billing processes
- Deferred lower-priority edge cases and refinements, documented and prioritised rather than dropped
- Aligned Customer Success and other stakeholders
- Prepared consolidated process documentation
- Prepared workshop materials
- Presented complexity, priorities and trade-offs to senior management
Key decisions
- Put information where teams already workClosure status is visible directly on the booking, so teams don’t need separate lists or manual cross-checks.
- Reduce repetitive data entryWhere information already exists, follow-up workflows reuse it instead of asking employees to enter it again.
- Use one source event for timingCustomer communication is calculated from a defined closure milestone, so the timeline stays consistent.
- Protect high-risk workflows firstCustomer communication, relocation or termination, and correct billing have the greatest customer and operational impact.
- Defer deliberatelyLower-priority edge cases are documented and scheduled rather than allowed to jeopardise the critical path.
- Make trade-offs visibleWhen scope changes materially, senior stakeholders should understand what is being prioritised, what is being deferred and why.
Technical and operational complexity
The main complexity was orchestration rather than one technically difficult feature. A single location closure affected several connected domains:
- Booking system
- Customer communication
- Salesforce / CRM
- Billing and prorated invoices
- Location data
- Customer belongings
- Relocation logic
- Termination logic
- Customer Service
- Operations
Each part had its own rules, but the workflow only worked if the systems and teams moved in the correct sequence. The product challenge was therefore to define clear states, triggers, ownership and exceptions across the entire lifecycle.
Why automation and visibility mattered
A structured workflow reduces the risk of customers receiving incorrect or late communication, customers being unable to relocate correctly, incorrect billing, unclear internal ownership, customers being missed in manual tracking, and teams acting on inconsistent information.
Outcome
The work helped move location closure from a highly manual, ad-hoc process toward a repeatable digital workflow with clearer ownership, better internal visibility and more consistent customer handling.
Internal teams gained clearer visibility into which customers were affected, which actions had already been completed and which still required follow-up.
Automation and structured workflows reduced reliance on manual coordination and created a more scalable approach for handling future closures.
What I learned
Some of the hardest product problems are not about building a new interface. They are about getting several existing systems, teams and business rules to move in the right sequence.
I also learned that when scope changes materially, prioritisation is not only about what creates the most value. It is also about protecting customers and operations from the highest-risk failure points.