Support
Help that understands event day
Four routes in, all read by the team that builds the product. Pick the one that matches what you need and it arrives with the context we need to act.
- 01Reply from a person
Request a walkthrough
Talk to us about onboarding an organization, pricing, or a security review. Fastest route for anything pre-sales.
Explore - 02Triaged by severity
Report a bug
Something broke on a pad, board, or overlay. Include the match ID and which surface — say if it is blocking a live event.
Explore - 03Read by the builders
Request a feature
Describe the event-day workflow you need. Operator requests drive most of what we build next.
Explore - 0417 answers
Read the FAQ
Sign-in, reconnection behaviour, public boards, sports coverage, and how plan gates fail. Most answers are already here.
Explore
Mid-event
If something is wrong right now
Three things to check before you write anything, in the order that resolves fastest.
01
Check the live layer first
Operators get an in-app connection banner the moment the socket service degrades. If pads have gone quiet, that banner tells you whether it is the network or the match.
02
Match state survives the device
State lives on the server. Reload the pad or open the board on another device — you are not rebuilding the score from memory.
03
Then send it with the match ID
A bug report with the match or event ID gets us to the exact bout in the logs. Mark it as blocking and it goes to the front.
At /login with your organization's client name and user ID, or at your own federation URL — a subdomain or /t/{slug}/login — which also carries your branding.