A value-added service layer over a racket-sports club CRM: booking → court camera → automatic game video

Context

Padel clubs increasingly run their operations on a dedicated racket-sports CRM: it owns court scheduling, bookings, membership, and payments. That CRM is the system of record — but it stops at the booking. Once players walk onto the court, the most emotional, most shareable moment of the whole experience — the game itself — produces nothing the club can give back. The video that players actually want, and would readily share, simply isn't captured or delivered.

The studio already solved the hard half of this problem in a separate case: a video infrastructure for a sports chain that goes from court booking to a player highlight reel, with real deployments. What's missing is the bridge to clubs that don't run on the studio's own stack but on a third-party CRM. Those clubs can't adopt the video product without a way to connect it to the bookings that already live in their CRM.

This is a deliberately honest, pre-integration case. No API access to the CRM has been granted yet. Rather than present shipped work, it sets out the product thesis, a proposed integration architecture, and a pilot plan — the credible pipeline behind a real product, not a claim of delivery. Framing it this way is the point: it reads as a scoped opportunity with a clear technical path, not as vaporware.

The task

Define a value-added service layer that a padel-club CRM can offer its clubs without the studio owning the booking system. The flagship user flow is a single arc: a player books a court in the CRM as usual, a court-side camera records the session, and the system automatically produces and delivers the game video to that player.

The commercial thesis is that video is a retention and add-on lever the CRM doesn't currently have. Players who receive shareable highlights come back more, share the club to their network, and are willing to pay for a recorded-game upgrade. The service layer monetizes on top of the CRM's existing booking relationship rather than replacing any part of it.

The engineering task at discovery stage is to specify how the layer attaches to a system whose internals aren't yet accessible: what events it needs from the CRM, how camera segments are matched to bookings, and how the video is delivered — all designed so the first grant of API access leads straight into a scoped pilot rather than a rebuild.

Approach

The service layer attaches to the CRM through integration adapters over its booking events, not by forking or replacing it. The minimum the layer needs is a stream of bookings — court, time window, and player identity — from which everything downstream is derived. Designing to the thinnest possible event contract keeps the integration portable across CRM versions and reduces what has to be negotiated for the first pilot.

The capture-and-delivery core is not built from scratch: it reuses the studio's existing padel video platform, which already implements court recording and player highlight delivery. The new work is the seam — matching camera segments to CRM bookings by court and time window, and routing the finished clip to the right player — rather than the video pipeline itself. Building on a proven core is what makes the pilot low-risk.

Delivery is through a mini-app: the player receives the clip where they already are, tied to the booking they already made. The architecture deliberately isolates the CRM dependency behind the adapter layer, mirroring the studio's standard practice of quarantining third-party integrations — so when the CRM's booking API changes, only the adapter changes, and the video core keeps working.

Proposed architecture

Three layers, with the CRM dependency confined to the first. The adapter layer subscribes to (or polls, if no push is available) the CRM's booking events and normalizes them into an internal booking record: court, time window, player. This is the only component that knows the CRM's shape; everything above it works on the normalized record.

The matching layer bridges bookings and camera footage. Court-side cameras produce continuous or segmented recordings; the matcher aligns a booking's court and time window to the corresponding footage and hands a cut instruction to the video core. This is the genuinely new engineering versus the existing platform, and the part the pilot most needs to validate against real camera timing and clock drift.

The video-and-delivery layer is the studio's existing padel platform: FFmpeg-based segment cutting and highlight assembly, and delivery of the finished clip to the player through a Telegram Mini App tied to the original booking. Because this layer is already proven in production, the pilot's risk is concentrated in the adapter and matcher, which is exactly where discovery-stage validation should sit.

Pilot plan

The pilot is scoped to a single club and a small set of cameras. Step one is the API grant and adapter build: subscribe to booking events and confirm the normalized booking record against real reservations. Step two is the matcher against live camera footage, validating court-and-time-window alignment under real clock drift. Step three is end-to-end delivery of a finished clip to a player through the mini-app.

The pilot's success criteria are defined up front — booking-to-video latency, delivery rate per booked hour, player opt-in and share rate, and incremental revenue per club — but deliberately left unpublished until they are measured, not asserted. The figures this case does state are structural facts of the design; a discovery case that published invented performance numbers would undermine exactly the credibility it needs.

Success at pilot converts the concept into a rollout: the adapter generalizes across the CRM's client clubs, the video core is already there, and the service layer becomes a revenue line the CRM can offer as an upgrade. The honest framing — proven core, unbuilt bridge, scoped pilot — is what makes this a pipeline opportunity rather than a promise.

What we built

• Booking-event adapter (proposed)

  Subscribes to or polls the CRM's booking events and normalizes them into an internal record — court, time window, player. The only component that knows the CRM's shape; everything above works on the normalized record.

• Camera-segment matcher (proposed)

  Aligns a booking's court and time window to court-side camera footage and hands a cut instruction to the video core — the genuinely new engineering versus the existing platform.

• Video core (reused)

  The studio's existing padel video platform: FFmpeg-based segment cutting and highlight assembly, already proven in production — reused rather than rebuilt.

• Mini-app delivery

  The finished clip is delivered to the player through a Telegram Mini App tied to the original booking, where the player already is.

• Isolated CRM dependency

  The third-party CRM is quarantined behind the adapter layer, following the studio's standard integration practice — when the booking API changes, only the adapter changes.

• Scoped pilot design

  A single club and a small camera set: API grant and adapter, then the matcher against live footage, then end-to-end delivery — validating the seam, not the proven core.

Engineering challenges