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
Date-Based Edge Case Handling
Identified and explicitly handled all date-based edge cases in job creation logic before engineering handoff - created documented decision matrix to ensure correct due dates across all scenarios, preventing contractor scheduling errors
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
Job Auto-Acceptance Behavior
Implemented automatic job acceptance to remove manual Customer Success bottleneck - jobs transition to active state without requiring contractor confirmation, streamlining the workflow
Key Tradeoffs
Multi-stakeholder systems design requires navigating competing priorities. Here are the critical tradeoffs made and their long-term impact.
⚖️Speed to Market vs. User Experience
Decision
Repurposed existing CSV import instead of building contractor-specific UI
✅What We Gained
- •Launched on timeline - business could begin operations immediately
- •Validated commercial model before committing to custom tooling
- •Engineering capacity freed for core workflow automation
⚠️What We Sacrificed
- •Contractors faced context mismatch - import designed for different use case
- •Required ongoing Customer Success support and training
- •Not self-serve - increased support burden
📊Outcome
Right call for phase 1. Customer Success overhead data secured commitment for purpose-built solution in future roadmap.
⚖️Automation vs. Operational Risk
Decision
Phased delivery with documented manual steps in early phases
✅What We Gained
- •Business could operate before full automation complete
- •Real user feedback informed later phase design
- •Risk contained - manual oversight during validation period
⚠️What We Sacrificed
- •Customer Success team performed manual handoffs in phase 1
- •Temporary operational burden before automation delivered
- •Required formal documentation and ownership of manual processes
📊Outcome
Phased approach validated workflow assumptions before locking in automation. Customer Success feedback improved phase 2 design.
⚖️Feature Completeness vs. Technical Debt
Decision
Accepted date-based edge case complexity upfront
✅What We Gained
- •Correct due dates for all scenarios - no contractor scheduling errors
- •Prevented downstream operational issues at scale
- •One-time engineering investment vs. ongoing manual correction
⚠️What We Sacrificed
- •Additional engineering time to handle all edge cases
- •More complex logic requiring careful testing
- •Delayed delivery slightly to get it right
📊Outcome
Investment paid off - zero contractor scheduling errors post-launch. Avoided entire category of support escalations.
⚖️System Integration vs. Clean Architecture
Decision
Integrated with legacy Odoo CRM for billing instead of rebuilding
✅What We Gained
- •Leveraged existing financial infrastructure
- •Finance team continued using familiar tools
- •No data migration or dual-system reconciliation
⚠️What We Sacrificed
- •Limited by Odoo capabilities and constraints
- •Integration complexity across multiple legacy systems
- •Less control over billing UX and timing
📊Outcome
Pragmatic choice - avoided re-platforming finance systems. Worked within constraints rather than fighting them.
⚖️Flexibility vs. Consistency
Decision
Built communication suppression framework with explicit rules
✅What We Gained
- •Prevented incorrect notifications to wrong stakeholders
- •Every suppression decision documented and intentional
- •Scalable approach - rules could be extended for new scenarios
⚠️What We Sacrificed
- •Upfront time to map all communication scenarios
- •More rigid system - changes required code updates
- •Could not handle ad hoc exceptions easily
📊Outcome
Rigidity was a feature, not a bug. Prevented notification chaos as system scaled. Worth the structural investment.
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.