CCase Study · Product Design, Systems Design & Implementation
Role: Product & Systems Designer, Developer
Client: Clean Care Aid Group (CCAG)
Scope: Service design, workflow architecture, UX, operational tooling, dynamic quoting, implementation
Status: In active operational use
Overview
Small service businesses operate through interconnected activities: acquiring customers, preparing estimates, scheduling work, coordinating staff, tracking jobs, and maintaining records. For Clean Care Aid Group (CCAG), I designed and built HUMBR, an operational environment connecting these activities through purpose-built interfaces, existing software, and shared documentation.
The work extended beyond interface design. It involved understanding how the business operates, translating its rules into working systems, and connecting operational workflows with the information they depend on.
Key outcomes:
- Quote preparation time reduced from nearly a full day to minutes
- Pricing model restructured to reflect actual operating costs, stopping financial losses
- System now used daily by CCAG staff for lead management, quoting, and operations
The Problem Space
Disconnected operations
Operational information accumulated across different applications, documents, and communication channels. Customer records, estimates, schedules, and job details each had their own source of truth. This created a systems-design problem: a quote depends on services requested and delivery costs; a schedule depends on available capacity and committed work; reporting depends on reliable records.
The pricing crisis
More critically, the existing pricing structure was hurting the business. Static pricing couldn’t account for changing operating costs, creating a disconnect between prices offered and resources required. Quotes were based on outdated assumptions, and the business was losing money on contracts without realizing it.
The challenge was to establish a connected operational model that reflected the actual business, supported daily work, and could evolve alongside changing requirements.
My Role
I worked across product definition, systems architecture, UX design, and implementation:
- Mapping business processes and operational dependencies
- Translating business requirements into workflows and system behavior
- Designing interfaces for operational tasks and decision-making
- Developing a dynamic quoting model informed by operating expenses
- Connecting existing platforms (Jobber, Google Sheets) via API with purpose-built capabilities
- Implementing working software and refining it through practical use
The work combined service design, product design, and software development within one continuous process.
Designing the Operational Model
01. Lead Management
The lead-management workflow connects customer inquiries with subsequent stages of the service process. The design focus is continuity: information captured early remains useful throughout the customer relationship.
The lead detail page consolidates everything needed for sales outreach: contact research, call readiness checks with missing-item flags, structured call prep with qualifying prompts and objection handling, and activity logging. Each section serves a specific operational purpose while maintaining context from previous interactions.
The system tracks lead progression through two layers: pipeline stage (intake, contacting, discovery, quoted, negotiation, won, lost) and lifecycle status (new, qualified, unqualified, won, lost). Call readiness checks prevent outreach until critical blockers are resolved—missing decision-maker paths, undefined opportunity types, or thin research summaries.
02. Dynamic Quoting Engine
This was one of the most important problems I addressed. A static price list provides consistency but cannot account for changing operating costs.
The pricing formula:
Final Price = Cost-Based Base Rate × Intensity × Schedule / Scope Adjustments × Margin Target
The base rate includes both direct field costs (cleaner wages, payroll burden, supplies, equipment wear) and operating overhead (supervision, insurance, vehicle costs, software, rent). The system enforces: never price from wages alone.
Intensity as the main pricing driver:
Rather than arbitrary surcharges, the model uses intensity multipliers reflecting actual site conditions:
- Light (1.00): Quiet office, low mess, limited detail
- Standard (1.10–1.20): Normal mixed traffic, visible common areas
- Heavy (1.25–1.40): Busier site, more washrooms, more touchpoints
- Premium/Complex (1.45+): Luxury presentation, strict QA, high-detail areas
Connecting pricing to operating reality:
Operating expenses are tracked in Google Sheets and transferred into HUMBR. The system maintains a live expense baseline. As costs change, the internal cost floor updates automatically. For example, with monthly expenses of $48,844.63 and 1,096.5 billable hours, the internal cost floor sits at $36.52/hr. At a 30% target margin, the blended sell-rate floor becomes $52.17/hr.
Before issuing any quote, the system requires confirmation that the baseline snapshot matches the live workbook. This prevents quotes based on outdated cost assumptions.
The quote creation interface brings all pricing inputs into one place: workload and hours, rate and multipliers (target margin, base wage, payroll burden, intensity, access), expense burdens (supplies, equipment, transport, admin, insurance, software), and quote content (scope summary, assumptions, pricing summary).
Guardrails and sanity checks:
The model includes market sanity checks ($35–$55 per cleaner-hour for Toronto recurring office cleaning) and rules for handling non-standard scope (deep cleaning, post-construction, carpet extraction) as separate line items rather than burying them in standard janitorial pricing.
Result: Quote preparation time dropped from nearly a full day to minutes. More importantly, the pricing model now reflects actual costs, stopping financial losses on underpriced contracts.
03. Scheduling and Job Tracking
HUMBR imports Jobber data via API, using it as the operations truth for scheduling, invoicing, and execution. The relationship between the schedule and job record is maintained so planned activity and completed work remain connected for coordination, reporting, and follow-up.
04. Reporting and Documentation
HUMBR connects reporting and documentation with the workflows they support. A Wiki.js knowledge base (~60 repo-managed pages) documents operating procedures, system architecture, and business rules. This provides a foundation for maintaining business knowledge and reviewing operational activity, supporting continuity as the business develops its processes.
System Architecture
Designing across tools and workflows
HUMBR operates as a hub within a broader environment of connected platforms:
- HUMBR: Central operational hub—lead management, quoting, workflow coordination
- Jobber: Customer, job, and service-management operations (imported via API)
- Google Sheets: Expense tracking and quote workbook calculations
- Linear: Work tracking and coordination
- Wiki.js: Structured documentation and knowledge base
- BRRM: Connected operational capabilities
Each component serves a different purpose. The design challenge was establishing clear relationships between them while keeping the overall system understandable and maintainable. This approach allows the business to use established tools where they fit and introduce custom functionality where requirements call for it.
From Design to Working Software
HUMBR was developed through an iterative process connecting business requirements, interface design, and implementation. AI-assisted development tools (Codex, OpenCode, Antigravity) supported the work, making it possible to explore solutions, build interfaces, test behavior, and refine implementation within the same workflow.
My role extended across these stages, with responsibility for product logic and the resulting experience. The work was evaluated against operational requirements and actual use, rather than ending with a set of design files.
Impact
Business operations:
- Structured lead management with call readiness checks and activity tracking
- Quote preparation time: ~1 day → minutes
- Pricing model restructured to reflect actual costs, stopping financial losses
Financial operations:
- Dynamic quoting informed by current operating expenses
- Pricing calculations accounting for costs at the dollar level
- Market sanity checks and guardrails preventing underpricing
System capabilities:
- Connected workflows across Jobber, Google Sheets, and custom tools
- Shared operational information and documentation (~60 pages)
- Extensible foundation for further development
Reflection
HUMBR illustrates how product design can extend beyond individual screens into the structure of a business. The most consequential design decisions concern relationships: how information moves between workflows, how business rules affect interface behavior, and how one operational decision influences another.
The quoting engine is a clear example. Its value comes from connecting a user-facing task with the underlying economics of the service business. The interface brings all pricing inputs into one place, but the real work was designing the calculation model, intensity tiers, and guardrails that make quotes accurate and profitable.
Building HUMBR also reinforced the relationship between design and implementation. Working code makes system behavior tangible, exposes gaps in requirements, and allows ideas to be evaluated against actual workflows. The pricing crisis made this concrete: the system didn’t just need to work—it needed to reveal when the business was losing money.
My approach combines systems thinking, interaction design, and implementation to create software that addresses real operational needs. HUMBR is an ongoing application of that approach.
