"Can you do Thursday 4pm?"
"Let me check... yes that works."
"Great! Rink A or Rink B?"
"Rink A. Can you remind me Tuesday night?"
"Sure. See you Thursday!"
If you're an ice skating coach, you've had this conversation hundreds of times. Via text. While teaching another student. While your phone is buzzing in your bag at the rink.
Manual coordination is exhausting. But instant booking feels wrong - you need to know who's booking before you commit.
We built something in between for Rinkly: structured booking requests where parents propose times and coaches approve in one click.
Here's why we designed it this way.
The Problem: Manual Coordination Doesn't Scale
Every ice skating coach we talked to hit the same wall around 12-15 students: manual scheduling becomes a second job.
Here's what ice skating coaching looks like from 10,000 feet:
Parents pay for lessons, manage their child's schedule, coordinate transportation, and need visibility into what's happening.
Coaches manage ice time (expensive and limited), balance multiple students, handle cancellations, and maintain their teaching quality by controlling how many students they take on.
Skaters (the kids) show up and learn. They're not making the decisions.
The relationship requires trust on both sides. Parents trust coaches to teach well. Coaches trust parents to show up and pay. But when you're building a platform, you can't assume trust exists - especially for new relationships.
The question wasn't "should we require approval?" but "who should approve what, and when?"
Why Instant Booking Doesn't Work
Instant booking works great for hotel rooms and restaurant tables. For ice skating coaching? Not so much.
The Coach Perspective
Coaches can't treat availability slots like commodity inventory because:
Context matters. A slot at 6am Saturday works for competitive skaters training for regionals. It doesn't work for a recreational 7-year-old trying skating for the first time.
Skill levels vary. A coach might publish availability for advanced students but not want beginners in certain time slots (early morning ice is fast, intimidating for new skaters).
Student mix matters. Some coaches avoid scheduling all their competitive students back-to-back (exhausting) or all their beginners consecutively (need variety to stay engaged).
Ice quality varies by time. Morning ice is fast and hard. Afternoon ice gets chewed up. Evening ice is tired. Coaches have preferences about which students skate when.
Personal limits exist. Even if a slot is "available," a coach might look at their week and realize they're overbooked. They need an escape valve.
The Parent Perspective
Parents don't want to book something the coach will immediately cancel. That creates three problems:
- Wasted time - Arranged transportation, cleared the schedule, now scrambling to undo it
- Child disappointment - "You have skating today!" followed by "Never mind" is rough on kids
- Platform trust erosion - If bookings don't stick, why use the platform?
Instant booking optimizes for speed, not for relationships. In a world where every booking has context and every participant brings history, speed without validation creates chaos.
Why Pure Manual Coordination Is Worse
Before Rinkly, most coaches coordinated via text, email, or phone calls. This has its own problems:
No shared calendar. Parents text "Is Thursday 4pm available?" Coach checks personal notes or memory. Sometimes they're wrong. Conflict discovered later.
No audit trail. "I thought you said Tuesday, not Thursday." "No, you said you'd let me know by Monday." He-said-she-said with no receipts.
Asynchronous delays. Parent texts at 9am. Coach sees it at 2pm (they were teaching). Responds at 4pm. Parent doesn't see it until 7pm. That's 10 hours for one round-trip.
Cognitive overhead. Coach is tracking requests in their head. "Did I confirm with Sarah's mom? I think so. Let me check my texts. Wait, was that about Saturday or Sunday?"
Missed opportunities. Coach has an opening. How do they tell everyone? Group text? Some parents opted out. Individual texts? That's 20 messages. Post on social media? Not everyone checks.
Manual coordination works at small scale (3-4 students). It collapses at real scale (15+ students). And it leaves no room for growth - every new student adds overhead.
The Request-and-Approve Design
We landed on structured requests with coach approval. Here's how it works:
Step 1: Parent Requests a Booking
Parent browses coach's published availability. They see open slots with dates, times, rinks, and durations.
They select a slot, choose which child it's for, select duration (if partial booking), optionally add a message, and submit.
What this creates:
- Structured data - Date, time, child, coach, location. Everything in the database, nothing in memory.
- Explicit intent - Parent has actively chosen this time. Not "maybe Thursday works" but "I want Thursday 4pm."
- Optional context - Parent can add notes ("Emma has a competition next week, needs extra practice") or leave it blank.
Step 2: Coach Sees the Request
Coaches get a notification: "Sarah's mom requested a booking for Emma on Thursday 4pm (30 min: 4:00 PM - 4:30 PM)."
For more details, coaches can click into the slot to see the full breakdown:
They see:
- Who requested (parent name)
- Who it's for (child name)
- When (date + time)
- Where (rink)
- Duration (if partial booking)
- Message (if parent included one)
- Time breakdown (booked/pending/available minutes)
- Their current week's schedule
Coach has context to make a decision:
- Do I know this student? (Check connection history)
- Does this time actually work for me? (Look at full calendar)
- Is this appropriate for their skill level? (Morning ice, afternoon ice, etc.)
- Am I overbooked this week? (Check session count)
- What's the parent's context? (Read the optional message if provided)
- How much time is left in this slot? (Check availability breakdown)
Step 3: Coach Approves or Declines
If approved:
- Session auto-created in calendar (not two steps - approve = create)
- Both coach and parent see it on schedules immediately
- Parent gets notification: "Coach Sarah approved your booking for Emma"
- Email sent (if parent wants emails)
- Slot capacity updated (marks as booked if full)
If declined:
- Booking request status → `declined`
- Parent gets notification: "Coach declined your booking request"
- Coach can optionally include a message ("This slot works better for advanced students - how about Saturday 3pm?")
- Slot remains available for others
If ignored:
- Request stays `pending`
- Parent sees "Pending approval" on their bookings page
- Coach sees it in their queue
- No auto-expiry (we debated this, chose not to add time pressure)
The Edge Cases We Handled
Partial Bookings (Time Blocks)
Some coaches offer group-sized slots (e.g., 2-hour Saturday morning window) but book them in smaller chunks based on lesson duration.
Without partial booking support: Parent books the full 2-hour slot for a 30-minute lesson. Wasteful.
With partial booking: Parent selects their desired lesson duration (15 min, 30 min, 45 min, 60 min, or full slot). The system divides the slot into equal blocks based on that duration and shows available time blocks.
Examples: - 1-hour slot + 15-min duration = 4 blocks (4 students can book) - 1-hour slot + 30-min duration = 2 blocks (2 students can book) - 2-hour slot + 30-min duration = 4 blocks (4 students can book)
Why this matters: Coaches want to publish fewer slots (easier to manage) but book them efficiently (more students, more revenue).
How it works: Parent picks duration (shown in Step 1 screenshot above), system calculates how many blocks fit in the slot, parent picks their preferred time block. System prevents overlapping bookings and tracks which blocks are still available. Coaches see the time breakdown in their slot details view (shown in Step 2 screenshot above).
Multiple Pending Requests
Parent requests Saturday 10am. Coach hasn't responded yet. Parent also requests Sunday 2pm as backup.
Naive approach: Block all new requests until coach responds.
Our approach: Allow multiple pending requests, different slots. System shows "Pending" status on both. When one is approved, others stay pending (parent might want both). When one is declined, others remain viable.
Why: Parents plan ahead. Blocking them from requesting alternates makes no sense. Coaches can see all requests, approve multiple if they want.
Edge case: Parent accidentally requests the same slot twice (double-click). System prevents duplicates - you'll see your existing request instead of creating a second one.
Cancellations After Approval
Parent requests, coach approves, session created. Then parent cancels (kid got sick, schedule changed, etc.).
Two-phase delete: 1. Booking request status → `cancelled` 2. Session marked as `is_cancelled: true` (soft delete)
Why soft delete: Preserves history. Coach can see "parent cancelled" vs "coach cancelled" vs "never happened." Matters for patterns (this parent cancels frequently, might not be reliable).
Slot behavior: When session is cancelled, availability slot capacity decrements. If slot was fully booked, it becomes available again. System sends notifications to parents who previously got "Slot Full" message (planned feature, not yet implemented).
Coach Changes Mind After Approving
Coach approves, then realizes they made a mistake (double-booked themselves, misread the time, etc.).
Coach can cancel the session. Same soft-delete behavior. Booking request stays `approved` (they did approve it), but session shows `is_cancelled: true`.
Parent sees: "Session cancelled by coach." Not ideal, but honest. Better than session mysteriously disappearing.
Why we allow this: Mistakes happen. Forcing the session to stay creates worse outcomes (coach doesn't show up, parent drives to rink for nothing).
Request Conflicts with Direct Scheduling
Parent has Direct Scheduling Permission with a coach. Parent also submits a booking request to that same coach.
Question: Should the request bypass approval (they already have permission)?
Answer: No. Different workflows for different purposes.
- Direct Scheduling = Coach adds sessions whenever they want, parent sees them (established relationship)
- Booking Requests = Parent proposes time, coach approves (parent is asking)
Even with permission, if parent is requesting via booking flow, coach should approve. It's about who's driving the action.
Example: Coach has permission to schedule Emma anytime. Emma's mom browses availability, sees a new Saturday slot the coach just published, books it via booking request. Coach sees the request, thinks "Oh yeah, that works for Emma," approves. System creates session.
This keeps the two flows separate and predictable.
Design Principles We're Testing
1. Hypothesis: Approval Isn't Friction When It's Fast
We're betting that one-click approval feels faster than text coordination, not slower.
Text coordination: Read message → Check calendar → Type response → Wait for confirmation → Manually add to calendar. 2-3 minutes minimum, often with context switching (phone buzzes during teaching).
Approval workflow: Notification appears → Tap "Approve" → Session auto-created on both calendars. 3 seconds, structured.
The bet: Structured approval beats unstructured confirmation, not despite the approval step, but because of it. The workflow automates what coaches already do manually.
What could go wrong: Coaches might perceive any approval step as "extra work" regardless of how fast it is. We'll find out when they use it.
2. Hypothesis: Parents Prefer Requesting to Taking
We think parents will prefer request-based booking even though instant booking is technically faster.
Why: Even with published availability, there's social context. Parents are asking to occupy the coach's time. Requesting feels respectful. It acknowledges the coach's agency.
The bet: Social norms matter more than speed. "Asking permission" isn't friction - it's politeness encoded into software. The relationship dynamic (parent asks, coach decides) should be reflected in the tool.
What could go wrong: Parents might find approval wait frustrating ("Just let me book!"). Speed might trump social norms. We'll see.
3. Hypothesis: The Ability to Decline Makes Yes Meaningful
We expect coaches to approve most requests (85-95%), but that small decline rate (5-15%) is critical.
Why it matters:
- Coach feels comfortable saying no (system isn't forcing yes)
- Parent gets clear feedback (not ghosted, not uncertain)
- Relationship preserved (explicit no beats silent resentment)
Example declines we anticipate:
- "This is a beginner slot, your daughter is advanced - how about Saturday 3pm?"
- "I'm overbooked this week, can we do next week?"
- "I'm taking that week off, forgot to unpublish - sorry!"
The bet: Approval rates stay high *because* coaches can decline when needed. The escape valve paradoxically increases commitment.
4. Design Decision: Messages Are Optional (But Available)
We made the message field optional for both parents (when requesting) and coaches (when declining).
Why optional:
- Most booking requests don't need explanation ("regular Thursday lesson" is implied)
- Required fields create form friction
- Empty messages communicate nothing, so forcing them is pointless
Why available:
- Context sometimes matters ("Emma has a competition next week, can we focus on jumps?")
- Declines feel harsh without explanation ("This time doesn't work - try Saturday?")
- Edge cases need communication ("I'll be traveling that week, didn't unpublish in time, sorry!")
The bet: Optional fields get used when valuable, ignored when not. The system accommodates both high-context and low-context communication styles.
What we expect: 20-30% of booking requests include messages. 40-50% of declines include messages (higher because rejection without explanation feels rude). Messages will be short (1-2 sentences, not essays).
What could go wrong: Parents might feel obligated to write messages even when unnecessary. Coaches might feel guilty declining without messages even when the reason is obvious.
5. Technical Decision: Auto-Session Creation Is Non-Negotiable
Early prototypes had two-step approval: coach approves request, then separately creates session.
Bad idea. Too easy to forget the second step. Approvals happen, sessions don't appear, everyone's confused.
Current approach: Approve = auto-create session. Coach clicks once, session appears on both calendars.
Why this matters: If approval always leads to session creation, make them the same action. Don't let humans forget deterministic outcomes. The system should handle the consequences automatically.
Building for Real Relationships
One of the hardest parts of building Rinkly was resisting the urge to optimize for metrics over relationships.
We could have built instant booking. Conversion rate would look better on a dashboard. "Time to first booking" would be shorter. We'd look more like a marketplace.
But we're not building a marketplace. We're building a tool for ongoing coaching relationships where trust, context, and mutual respect matter more than speed.
The approval step is social infrastructure. It encodes "parents ask, coaches decide" into the system. Even when approval is near-certain (established students, regular times), the act of requesting and approving reinforces the relationship dynamic.
Coaches aren't vending machines. Parents aren't just customers. Skaters aren't inventory. These are people who work together for months or years. The software should respect that.
Why This Matters for Other Builders
If you're building tools for service businesses (coaching, tutoring, therapy, personal training), resist the temptation to automate everything:
Ask yourself: Does this transaction require judgment? If yes, give humans the choice instead of forcing automation.
Example: Hotel room bookings don't require judgment (vacant = available). Coaching sessions do require judgment (context, skill level, coach capacity).
The instinct to optimize for speed is strong. It's tempting to remove every step, automate every decision, make everything instant. But sometimes the "slower" workflow better respects the relationship. The approval step isn't overhead - it's acknowledgment that one person is asking for another person's time, and that person deserves to decide.
Why We Think This Will Work
We've designed this workflow based on deep understanding of the problem, but we haven't validated it with thousands of real bookings yet. Here are the core bets we're making:
Bet #1: Coaches Want Control, Not Just Speed
Instant booking is faster on paper. But coaches would rather take 30 seconds to approve than have unwanted sessions appear on their calendar.
What we expect: Coaches will appreciate seeing who's requesting before they commit. They'll value the ability to check their full schedule, consider student skill level, and occasionally say no - even if it adds a few seconds to the workflow.
How we'll know we're right: Coaches use the approval workflow regularly without complaining about it being "extra work." Decline rate stays in the 5-15% range (proves they feel comfortable saying no).
How we'll know we're wrong: Coaches request instant booking feature. Support tickets about approval being friction. Low adoption because the workflow feels slow.
Bet #2: Parents Prefer "Asking" to "Taking"
Even when approval is near-certain, the act of requesting feels more respectful than instant booking. The software should encode the social relationship, not flatten it.
What we expect: Parents will submit requests without feeling awkward. They'll appreciate seeing "Pending approval" status instead of wondering "Did they see my text?" The structured workflow will feel less intrusive than direct texting.
How we'll know we're right: Parents book regularly. Booking request submission rate is healthy. No feedback about feeling like they're "bothering" the coach.
How we'll know we're wrong: Parents avoid booking because they feel like they're creating work. Parents asking for instant booking instead.
Bet #3: Structured Beats Unstructured
Text coordination feels slow because of lack of structure, not because of the medium. Notifications, context, and one-click actions will beat "Did you see my text?" confusion.
What we expect: Coaches will approve requests faster than they currently respond to texts (we're guessing median approval time under 1 hour vs. several hours for text responses). Parents will appreciate visibility into request status.
How we'll know we're right: Average approval time is faster than manual coordination. Fewer "Did you see...?" follow-up texts. Both parties report less coordination overhead.
How we'll know we're wrong: Approvals take as long as text responses. Parents text coaches directly instead of using the system. The structure adds overhead rather than reducing it.
The Philosophical Point
The booking request workflow isn't about efficiency. It's about trust mediation.
In the early days of a coach-parent relationship, both parties are cautious. Parents want to know the booking will be honored. Coaches want to maintain control over their schedule. Neither wants to commit instantly.
Request-and-approve gives both parties agency:
- Parents propose without presuming
- Coaches accept without obligation
- Both see explicit confirmation
- Either can say no without awkwardness
As relationships mature, this workflow feels less necessary. That's fine. That's what Direct Scheduling Permissions are for. But for new relationships, first-time bookings, or unusual requests, the approval step is a feature, not a bug.
The best tools don't eliminate human judgment - they structure it so it's fast, clear, and leaves an audit trail.
Booking requests do exactly that. Parents ask. Coaches decide. Everyone knows what's happening. The tool gets out of the way.
That's what we built. We're confident in the design rationale. But we're also humble enough to know that real usage will teach us things we didn't anticipate.
The Honest Truth: We Don't Know Yet
This post describes how we designed Rinkly's booking system and why we think approval-based booking works better than instant booking or manual coordination.
But we don't have thousands of bookings validating these hypotheses yet. We don't have testimonials from coaches who've used this for months. We have thoughtful design decisions based on understanding the problem space.
The real validation comes when coaches actually approve (or ignore) requests, when parents book (or avoid booking) their first lesson, when the workflow either saves time or creates friction, and when people tell us what we got wrong. That's where design rationale meets reality.
We're confident enough in these design principles to ship them. We're betting that structured approval respects coaching relationships better than either extreme. But we're not claiming victory before coaches have used it.
If you're an ice skating coach reading this and thinking "I'd try that" - reach out. We'd love to hear your thoughts before you've used it, and especially after you do. The difference between design rationale and real-world validation is where the interesting insights live.
We designed this thoughtfully. Now we need to find out if we designed it well.
---
Want to be an early user? Rinkly's booking system is built for ice skating coaches, but the approval workflow should work for any coaching relationship where context and judgment matter. Learn more at rinklyapp.com or email us at support@rinklyapp.com to discuss what you'd need to try this.