The Service Beneath the Product

Designing the upstream — staff lifecycles, service blueprints, and the journeys that products live inside MainStory · 2024–2026

A collection of service-design artifacts that frame everything else: how a caregiver moves through MainStory's pipeline, how a parent experiences the first month, how the on-demand homecare service actually delivers, how trial conversion really works. The work below the screen.

The Setup

Most product design happens at the screen layer — buttons, flows, components. That's where the deliverables live, and that's where most designers are asked to spend their time.

But every screen-level decision is shaped by an upstream system: the service the product is wrapped around. How does a caregiver actually flow from application to active duty? What does a parent's first 30 days actually feel like? When the on-demand homecare service is dispatched, what's the chain of handoffs that determines whether the experience holds together?

When that upstream work isn't explicit, it gets implicit — encoded into screens by accident, invisible to anyone joining later, fragile when the business changes.

At MainStory, I made the upstream explicit. Not as a deliverable for someone else, and not as a "discovery exercise" preceding real work. The service blueprints became real artifacts that engineering, ops, sales, and finance all read from.

This case study is about that work.

Why Service Design Sits Where It Sits

Product design owns the interface. Operations owns the workflow. Strategy owns the business model.

Service design lives between them — the layer that connects what the customer experiences to what the business delivers. It's where you discover that a "great trial conversion experience" actually requires alignment between marketing copy, sales scripts, CM availability, child enrollment, payment timing, and the parent app onboarding flow. Get any of those out of sync and the trial converts at half the rate, even if every individual screen is well-designed.

At a 10-center, 200-caregiver company growing into something much bigger, this layer either gets named and owned, or it slowly breaks. I named it and owned it.

The Four Service Blueprints

Each blueprint solved a different upstream problem. Together, they became the service-architecture canon for MainStory.

Blueprint 1 — The Staff Database

The problem: A mitra asuh's status was different in every system she touched. Hiring saw "passed." Training saw "active." Operations saw nothing until an edge function fired. There was no single source of truth, and worse, no single concept of truth — different teams used different words to describe the same lifecycle stage.

The blueprint: A unified MECE status taxonomy spanning the entire caregiver lifecycle, from initial application to active employment, with sub-states (Active / Rejected / Resigned) for every stage and a structured note taxonomy for resignation reasons. Eight stages, three sub-states, one canonical model — enforced across hiring, training, and operations.

SCREENING      INTERVIEW_HR    PSIKOTEST     INTERVIEW_CM
  ↓ active        ↓ active        ↓ active        ↓ active
  · rejected      · rejected      · rejected      · rejected
  · resigned      · resigned      · resigned      · resigned
                                                       ↓
OFFERING       IN_TRAINING     MCU            ONBOARDED_REGULAR /
  ↓ active        ↓ active        ↓ active     ONBOARDED_ON_DEMAND
  · rejected      · rejected      · rejected
  · resigned      · resigned      · resigned

This taxonomy became the spec the Account Unification data architecture was built against. Service design above the system; system design below the service.

Blueprint 2 — HC On-Demand Service Blueprint

The problem: Homecare on-demand wasn't a product feature. It was a service — meaning every booking required real-time orchestration across parent app, dispatch logic, caregiver availability, transport, on-site arrival, care delivery, payment reconciliation, and post-care followup. Any single break in that chain destroyed the experience.

The blueprint: A complete service blueprint mapping each stage of the on-demand experience across three lanes: front-stage (what the parent sees), back-stage (what staff do), and support processes (what systems handle). For each step: trigger, actor, expected output, failure mode, and recovery path.

The blueprint surfaced things screens couldn't. Like: when a caregiver was dispatched but the parent's child was asleep, the existing "Caregiver arrived" notification felt invasive. The fix wasn't the notification — it was a quiet-arrival mode flagged at booking time, propagated through to the caregiver app, and surfaced in the dispatch handoff. That's a service-design fix, not a UI fix.

Blueprint 3 — Trial Flow User Journey

The problem: Trial conversion was the leakiest part of MainStory's funnel. Parents booked trials, but a meaningful share never showed up, never enrolled, or enrolled and churned within 30 days. Every team had a theory ("the trial pricing is wrong," "the CM doesn't follow up," "the booking flow is too confusing"). Nobody had the full picture.

The blueprint: A complete trial journey from first ad impression to monthly enrollment, plotting touchpoints across marketing, sales, operations, and product. Time on each stage. Drop-off rates per transition. Decision criteria the parent uses at each step (mostly tacit, surfaced through interviews).

The diagnosis: the leak wasn't in any single stage. It was a cumulative problem — small frictions stacking. The trial booking flow lost 15% of intent. The CM follow-up window was too long, losing another 20% of trial-attended-but-not-enrolled parents. The first-week-of-enrollment experience created another 10% churn at the 30-day renewal mark.

You can't fix a cumulative problem one screen at a time. The blueprint became the design brief for a coordinated multi-team intervention — not three separate projects.

Blueprint 4 — First 30-Day Parent Experience

The problem: The parent's first month at MainStory determines whether they stay for a year. But "first month" wasn't owned by anyone. Onboarding was the marketing team's job. The first daycare day was operations. The first invoice was finance. The first concerns ("is my baby okay?") were the CM's. Nobody saw the experience whole.

The blueprint: A 30-day experience map plotting every touchpoint the parent has with MainStory in their first month — from contract signing through the first invoice cycle, with explicit emotional curve mapping ("anxious," "reassured," "overwhelmed," "delighted") and explicit promise/delivery alignment ("we promised X; on day Y, did we deliver X?").

The output of this blueprint shaped multiple downstream products:

  • Monthly Wrapped was directly informed by the "day 30 emotional needs" identified in this blueprint — parents need evidence their child is thriving, not just photos.
  • The Notification Board's parent-facing channel taxonomy came directly from this work.
  • The first-week CM check-in protocol was redesigned based on the anxiety curve mapping.

This is the leverage of service design. One upstream artifact informs many downstream products. Done well, it makes everything afterward more coherent.

What Service Design Looks Like as a Discipline

I'm not a "service designer" by title. I'm a product designer who has internalized that the most leveraged work is often the work nobody is asking for.

Some patterns I apply:

Map the actor lanes, not just the steps. Front-stage / back-stage / support-process is the discipline of always asking: who is doing what, where, and what infrastructure are they leaning on? If I can't draw the back-stage, I don't understand the front-stage.

Make the emotional curve explicit. Service experiences aren't neutral — they have arcs. Anxious → reassured → invested. Confused → curious → confident. Naming the curve is the first step in designing for it.

Plot promise vs. delivery. Marketing says X. Sales says Y. The product delivers Z. The blueprint forces those into alignment. When they're misaligned, retention dies — not because the product is bad, but because expectations were set wrong.

Treat handoffs as design surface. Most service failures happen at handoffs — between teams, between systems, between stages. The boring transition between two stages is where most of my service design attention goes.

Outcomes (Indirect, but Real)

Service design rarely has a clean metric attached. The blueprints don't ship as products; they shape the products that do. So the metrics show up downstream:

  • Account Unification ships against a unified status taxonomy that didn't exist 18 months ago.
  • Monthly Wrapped addresses the day-30 emotional need this blueprint surfaced.
  • Notification Board routes events through a parent-experience model that came out of this work.
  • HC On-Demand operations runs against a blueprint that distinguishes service-level decisions from product-level ones.

The hidden metric: organizational coherence. When sales, ops, finance, and product all reference the same blueprint, decisions get made faster, contradictions get caught earlier, and the company moves like one team instead of four.

That's the work nobody asked for. It's also the work that scales the company.

What I'd Do Differently

I'd version-control the blueprints from day one.

The FigJam boards I built grew organically — adding stages, refining handoffs, surfacing new edge cases as they appeared in real operations. That's good. But without versioning, it became unclear which version of the blueprint a particular product decision was made against. When we revised the trial flow, was that against the blueprint from March or August?

Version-controlled service blueprints — with explicit "this is the source of truth as of [date]" markers and changelog entries — would have made the cross-team coordination tighter. Lesson: anything worth being canon needs to be versioned like canon.

TODO — second reflection: one more honest "I'd do this differently." What's the strategic miss here, separate from the tactical versioning point above? Maybe about who you involved in blueprint authoring? About which blueprints didn't get written that should have?

The Pattern

The most leveraged design work is often the work nobody is asking for.

Product design is reactive by default. PM has a brief, designer has a Figma file, engineering has a sprint. The process generates output, but the output stays at the level the brief was written at.

Service design is the practice of working at the level above the brief. Not against PM, but ahead of PM. Mapping the system the screens will eventually live inside, so the screens land in coherent context instead of accidental context.

I now treat service blueprints as a default first artifact for any cross-team product. They take a week. They save months.

This is the most direct embodiment of "I design operating systems, not interfaces" I have. The service blueprint is the operating system. The product is what runs on top.

MainStory · Indonesia's premium childcare platform · Service blueprints, journey maps, lifecycle models

← Back to all work