Service Model Workflow - Multi-Stakeholder Systems Design
PropTech B2B Platform, Systems Design and UX for New Commercial Model
Role
Product Manager & UX Designer
Timeline
3 phases delivered incrementally
Team
Software Development Manager, Business Analyst, QA Manager, QA Engineers, Engineers
Collaboration
Cross-functional team including engineering, operations, Customer Success team, finance team, and external stakeholders
Constraints
- No existing template or prior workflow to reference
- Multiple legacy systems requiring integration (mobile app, Odoo CRM for billing, email and SMS communications)
- Varied technical capabilities among contractors
- Phased delivery requirement - business needed to operate before full automation
- Complex eligibility rules for downstream offers had to be enforced at system level
Problem
The business established a new commercial model requiring a distinct operational and product workflow with no equivalent process to draw from. The model involved a unique financial arrangement between the business, external service contractors, and end users - each with different roles, responsibilities, and information needs. Multiple existing systems needed to interact to support the new model, none of which were designed to work together in this configuration.
Design Challenge
- Design a complete end-to-end workflow for a new commercial model with no existing template, covering every touchpoint from account setup through to multi-year billing
- Serve multiple user types - internal Customer Success team, external contractors, agencies, and end users - each with different needs, permissions, and actions at different stages
- Determine which parts of the workflow could be automated immediately, which needed to remain manual in early phases, and how to make manual steps as safe and consistent as possible
- Design a communication architecture that correctly identified who should receive what, when, and under what conditions
- Build a data import mechanism that met contractors where their existing behaviour was, rather than requiring them to adopt a new way of working
- Handle non-trivial date-based edge cases in job creation logic that would directly affect contractor scheduling
- Decouple eligibility-based downstream offer logic from the core workflow
- Deliver across three phases, with each phase needing to be operationally viable on its own

Process
- Mapped the full stakeholder landscape before designing anything - identifying every user type, their role in the process, and specific actions needed at each stage (Understand)
- Conducted working sessions with Customer Success team to understand manual steps already being performed and where pain and risk was concentrated (Understand)
- Worked with operations and engineering to understand constraints and capabilities of existing systems requiring integration (Understand)
- Mapped all existing communication templates and identified which applied, which needed suppression, and which needed creation from scratch (Understand)
- Documented every manual handoff point and assessed risk of each - distinguishing between temporarily manual steps and those manual due to lack of tooling (Define)
- Surfaced date-based edge cases in job creation logic that would have produced incorrect due dates if not explicitly handled (Define)
- Mapped eligibility logic for downstream offers and identified it needed system-level enforcement (Define)
- Validated phased delivery structure by mapping which workflow steps were dependencies of others (Decide)
- Made deliberate trade-off to repurpose existing CSV import function rather than build new import UI - prioritising speed to market (Decide)
- Created explicit handling for all date-based edge cases with documented decision matrix for engineering (Design)
- Built communication suppression framework with explicit rules per stakeholder type and workflow stage (Design)
- Designed job auto-acceptance behaviour to remove manual bottleneck (Design)
- Designed billing trigger as polling mechanism for multi-year invoicing (Design)
- Delivered phase 1 with functional Customer Success workflow and automated job creation (Validate)
- Incorporated Customer Success feedback from phase 1 before shipping phase 2 (Validate)
- Held team retrospective after each phase to capture learnings and improve subsequent phases (Reflect)
User Research Details
Stakeholders
Operations, Customer Success and Finance teams, external contractors, and agency users
Research Methods
Working sessions, stakeholder mapping, manual workflow observation
Research Focus
Understanding existing manual processes, pain points, system constraints, and varied technical capabilities across user types

Stakeholder Management
I led cross-functional working sessions with Customer Success, operations, and engineering teams to map the complete workflow from business intent to technical implementation. When the repurposed CSV import created friction for contractors during phase 1 rollout, I worked directly with the Customer Success team to document the support burden and advocate for a purpose-built solution in the roadmap. By presenting usage data and Customer Success overhead metrics to senior management, I successfully secured commitment for an automated contractor-specific import mechanism in a future phase.
Design Decisions
Phased Delivery Structure
Structured delivery into three discrete phases, each operationally self-contained, ensuring the business could begin operating before full automation while validating each phase with real usage
Repurposed CSV Import
Trade-off to repurpose existing agency CSV import for contractors rather than build new UI - accepted context mismatch in exchange for speed to market, with documented plan for purpose-built solution
Communication Suppression Framework
Built explicit suppression rules per stakeholder type rather than ad hoc suppression - every suppression decision documented and intentional to prevent incorrect email and SMS notifications
Eligibility Decoupling
Decoupled downstream offer eligibility from core workflow entirely - preventing Customer Success escalations and manual intervention at scale by enforcing at system level
Billing Polling Mechanism
Designed billing trigger as polling mechanism rather than one-time event - enabling multi-year invoicing without manual intervention for each cycle
Manual Steps as Design Decisions
Treated phase 1 manual steps as explicit design decisions with documented owners and risk ratings - not informal workarounds, with clear automation timeline

Outcomes
Phase 1
- Account setup process established with functional Customer Success workflow
- Repurposed CSV import delivered for bulk property date updates
- Automated job creation with correct due date logic across all edge cases
- Trade-off: CSV import required hands-on Customer Success support due to context mismatch - not self-serve but delivered on timeline
Phase 2
- Job auto-acceptance implemented, removing manual Customer Success bottleneck
- Blank subscription record creation automated on job completion
- Billing trigger activated, initiating year one invoicing
- Full stakeholder communication suite launched with suppression logic
- Two communication adjustments made based on phase 1 Customer Success feedback
Phase 3
- Multi-year billing polling mechanism delivered
- Polling logic increments billing date automatically for years 2-5+
- All manual financial processes removed from Customer Success team
Overall Impact
- All manual steps identified in discovery either automated or formally documented with ownership and risk ratings
- Communication architecture delivered with explicit suppression logic across all stakeholder types
- Eligibility-based offer logic enforced at system level - Customer Success no longer manually assesses account eligibility
- Phased delivery allowed real operational feedback to inform subsequent phase design
Reflection
Service model workflow design requires stakeholder mapping before any other design work - without a complete picture of who is involved and what they need, gaps only surface during build or after launch.
The date-based edge cases in job creation were not visible in the original brief and only emerged from deliberately working through the logic in detail before engineering handoff. This confirmed the value of pre-build logic review as a standard practice.
The repurposed CSV import was the right call given timeline constraints, but it introduced context mismatch requiring careful Customer Success support - given more runway, a purpose-built import UI would have reduced friction and Customer Success coordination burden.
Small logic decisions in workflow design have outsized operational consequences - the eligibility decoupling appeared minor but prevented an entire category of Customer Success escalations.
Tools
Note: This case study focuses on demonstrating my thinking, process, and decision-making approach. While the actual product designs and implementations remain proprietary, the emphasis here is on how I frame problems, conduct research, make strategic decisions, and measure success.