Remove the work that scales every time your player base grows.
- Every cancellation or player swap starts another manual conversation.
- Staff apply the same policy differently and managers resolve the fallout.
- Players wait for simple answers while the team handles on-site work.
- Growth creates more support volume, more admin and more owner involvement.
- Routine requests completed from the same rules your team already uses.
- Material changes confirmed and logged before they happen.
- Exceptions reach staff with the player, booking and context already attached.
- More players supported without turning the owner into the escalation desk.
What this does for your club
A Playtomic bot can automate routine player questions, booking lookups, reminders, player swaps, permitted booking changes and approved refund or cancellation workflows. The documented Playtomic Club API is read-only, so a credible supplier must distinguish data access from any separate authorised action workflow. The club should define the rules, the bot should confirm material changes and log every outcome, and anything involving discretion, unclear identity, unusual payment conditions or policy exceptions should go to staff with the full context attached.
Start with the jobs owners actually want removed
The high-value jobs are repetitive conversations that end in a known answer or a controlled action: opening hours, prices, access instructions, booking lookups, player changes, cancellations, refunds and reminders. A useful bot resolves the job. It does not merely recognise the topic and send the player elsewhere.
Write the club's cancellation, refund and player-change rules in plain language, then use the same rules for staff and automated workflows. Inconsistency is what creates long message threads, reopened cases and avoidable exceptions.
Okay, checked your data. Tuesday and Wednesday 1 to 4pm ran at 24% occupancy. I found 184 quiet players who used to play those exact times but haven’t been back in the last 60 days.
I’ve built them into a segment and drafted a WhatsApp message you can send.
What can be automated and what should stay human
- Automate: current prices, opening hours, access instructions and policy questions grounded in approved club information.
- Automate: booking identification, reminders and collection of the details required for a routine request.
- Automate with confirmation: authorised player swaps, court changes, cancellations and refunds.
- Escalate: unclear identity, unusual payment states, complaints, discretionary compensation and policy exceptions.
- Escalate: any request where the system cannot prove the intended booking or the permitted outcome.
Automate rules; escalate judgement
Pulse can answer the initial WhatsApp message, collect the needed details and carry out authorised routine actions such as player swaps, court changes and refunds. The club defines the boundaries. Anything unusual is handed to staff with the conversation context intact.
Measure no-show rate, late-cancellation rate, recovered slots, refund turnaround time and messages per incident. That shows whether automation is reducing loss, improving player experience or merely replying faster.
Map each common request to one controlled outcome
| Player request | Routine path | Escalate when |
|---|---|---|
| One player cannot attend | Confirm whether the booking remains and explain the replacement path | Payment responsibility or eligibility is unclear |
| Whole booking cancellation | Check policy window, payment method and authorised refund route | The request is late or policy allows discretion |
| Move court or time | Check the club rule and confirm the exact replacement before changing | Price, venue or availability creates a material difference |
| Wallet refund | Use the supported wallet workflow and record the movement | The plan, billing model or wallet status is not eligible |
| Injury, weather or facility fault | Collect the required facts | A manager must approve an exception or compensation |
Build every workflow around a useful next action
- Identify the player and exact booking without asking for information the system already holds.
- Include venue, date, time and the minimum booking identifier needed to avoid confusion.
- State the relevant cancellation or change deadline in plain language.
- Offer only actions the club can actually complete from that channel.
- Confirm a material change before execution and retain the decision trail.
- Escalate policy exceptions with booking and payment context already attached.
Important: Playtomic's current guide says a club cancellation normally returns an online payment to the original method, with bank settlement commonly taking 2 to 10 business days. Confirm current behaviour before promising a timing to a player.
How this guide was prepared
This capability map combines recurring player-support cases seen around live padel operations with Playtomic's current API, cancellation and wallet-refund documentation. Product behaviour can vary by plan, billing model, payment method and club policy, so the guide separates documented Playtomic behaviour from the rules and permissions a club must define itself.
Sources and verification
Product capabilities, policies and prices can change. These sources were checked on 29 August 2026.
Frequently asked questions
Can Pulse handle a player swap in Playtomic?
Yes. When the request fits rules authorised by the club, Pulse can swap players and log the action; unusual cases are escalated.
Does the Playtomic API make booking changes?
No. Playtomic documents the Club API as read-only. Any supplier that changes bookings should explain its separate authorised workflow, permissions and audit trail.
Which automation metrics matter?
Track correct resolution, staff handoff, reopened cases, refund or change completion, response time and the number of staff messages required per incident.