How Tunelark connected lesson sales, scheduling and instructor payouts
A lesson marketplace must keep bookings, customer credit, calendar availability, payment, instructor capacity and payout status aligned. New revenue features could not break the historical records and live workflows underneath them.
Devntech’s scope: Devntech delivered product engineering across the marketplace and its supporting integrations. Public marketplace scale is client context; this case attributes only the delivered product, payment, automation and reporting capabilities to Devntech.
Hero visual
The learner journey from trial lesson to paid booking
A learner journey showing the trial, prepaid credit, booking and instructor delivery state.
The engagement
What Devntech built for Tunelark
Tunelark connects learners and music instructors through a live marketplace. Devntech extended the existing platform with prepaid lesson packs, gift cards, lifecycle automation, capacity controls, payment observability and conversion reporting - while protecting booking and billing behaviour already in use.
What we changed
- 1
Added prepaid products and stored-credit workflows.
- 2
Connected scheduling, capacity and payout safeguards to marketplace state.
- 3
Improved observability and reporting across payment and acquisition workflows.
Qualitative evidence
What changed operationally
- Prepaid lesson products and stored credit operate against the same booking and billing records as existing lessons.
- Capacity, lesson delivery and payout state are connected, giving operations teams a shared record for intervention.
- Payment and acquisition activity is exposed through reporting and investigation workflows rather than manual list checks.
Evidence standard: These are delivered workflow and operating-state changes supported by the project record. They are qualitative results, not estimated percentages or modelled savings.
What Devntech continued to own
- Product engineering
- Marketplace integrations
- Operational automation
This is what we mean by
Workflow automationOperational flow
How the system works
The system is organized around three operational steps, with each handoff tied to a clear purpose and owner.
Workflow visual
Trial, stored credit, scheduling, delivery and payout
An annotated marketplace flow showing where calendar, payment and lifecycle systems connect.
Step 1
Convert a trial to credit
A learner can purchase a lesson pack or receive a gift, creating credit that follows the customer journey.
Step 2
Book without losing context
Scheduling, instructor availability and historical order data remain connected.
Step 3
Control delivery and follow-up
Capacity, payout eligibility, lifecycle messages and paid-conversion reporting use marketplace state.
What changed in practice
Capabilities built around the real workflow
Specific system capabilities, described by the operational job they do.
Product state
Lesson-pack balance and booking state
A redacted product view showing purchased credit, remaining lessons and the next booking.
- Prepaid packs and gift cards
- Creates additional ways for learners to commit to future lessons.
- Capacity and payout safeguards
- Connects availability and payment decisions more closely to lesson state.
- Lifecycle and conversion reporting
- Lets marketing and operations act on paid marketplace activity.
Implementation detail
What made this system difficult - and how we handled it
The decisions below came from the operating constraints of this engagement, not from a generic technology template.
A lesson booking is a chain of operational commitments
A marketplace lesson is more than a calendar event. The selected time has to remain correct for the learner and instructor, the calendar invitation must arrive, payment and stored credit have to reconcile, and payout eligibility must reflect whether the lesson was delivered. Marketing and lifecycle systems also need enough context to follow the same customer journey.
When those systems disagree, the failure becomes operational: a learner sees the wrong balance, an instructor remains available after reaching capacity, or support has to reconstruct a booking from several tools. Devntech treated booking, credit, capacity and payout as related states rather than independent features.
New revenue products preserved historical commercial records
Lesson packs let a learner purchase several future lessons after a trial, while gift cards introduce a buyer, a recipient and a later redemption event. Both depend on stored credit. Devntech designed the purchase record to retain the agreed price instead of recalculating old orders from settings that may change later. That keeps invoices, refunds and support conversations explainable.
The same principle shaped scheduling and supply controls. Instructor offerings can be removed when a configured capacity condition is reached and restored when availability returns. This reduces the risk of creating a sale that operations later has to unwind.
Operational state became useful to support and acquisition systems
Lifecycle automation can react to unpaid bookings, unused credit, inactive learners and unredeemed gifts without a team member assembling lists by hand. Payment errors carry booking, charge and instructor context into monitoring, making an exception easier to locate and investigate. Payout safeguards connect payment eligibility more closely to lesson-delivery state.
Devntech also connected completed paid sales back to advertising platforms so acquisition systems receive a signal from the revenue-producing event, not only the discounted trial. No conversion uplift is claimed without measurement. The durable lesson is that marketplace growth features work best when commercial state, delivery state and observability are designed together.
More like this
AI · Internal software · Integration
Fastyr AI
AI agent workspace
Internal software · Integration
Five to Nine
Workplace events platform
Got a workflow like Tunelark’s?
Describe the process. We come back with what it costs today, what could be automated and what we would build first.
- For businesses with $5M to $30M in revenue
- No long-term commitment
- Start with one workflow
- Keep ownership of everything we build