The Come support desk receives tickets through the verified contact form at /contact/. Verified: response window is 24 hours on weekdays. Unverified: weekend response windows vary by ticket volume; the published channel is the ticket form, not a chat surface.
Ticket form
The verified support channel is the ticket form at /contact/. Tickets carry the requester's contact details and the device state needed to reproduce the issue.
24 hours on weekdays
Verified: the support desk replies within 24 hours on weekdays. Weekend response windows vary by ticket volume and are listed on the support desk itself.
Source-backed answers
Verified fields include platform, install route, KYC state, payout route and self-limit tier. Unverified fields are listed as such rather than invented.
Before you open a ticket. Confirm the install route is the verified one at /install/. The support desk can resolve install, deposit, withdraw and KYC tickets without a screen share.
What the support desk resolves
Tickets that fall inside the verified surface get a source-backed answer. The desk resolves install tickets (settings, source toggle, hash mismatch), deposit and withdrawal tickets (payout route, KYC state, pending withdrawal state), KYC tickets (document set, address proof, payout route attachment) and account tickets (self-limit tier, notification preferences, VIP level). Each resolution references the same field the support desk verifies on the backend, so the ticket answer matches the answer the app shows.
What the support desk does not resolve
Tickets that fall outside the verified surface are not resolved on the ticket. The desk does not verify third-party offers, side-game outcomes, chat activity or any field that is not listed on the four Come surfaces (match data, roster, wallet, account). When a ticket falls outside the surface, the desk replies with the public documentation and the ticket is closed. This is not a deflection - it is the same answer any operator running on the verified surface would give.
How to write a ticket that resolves in one pass
The fastest tickets include: the device (Android version), the install route used (verified / unverified), the KYC state (complete / pending / failed), the payout route selected and the self-limit tier. With those fields, the support desk can reproduce the issue on the backend and respond with the verified fix. Tickets that omit those fields go back and forth while the desk reconstructs the device state, which is what extends the response window.
Ticket escalation path
Verified: tickets on the verified surface escalate to the second-line desk without a re-ticket. The first-line desk reads the ticket body, confirms the install route and the KYC state, and either resolves on the first reply or escalates with the snapshot timestamp attached. Unverified: tickets that fall outside the verified surface are closed with the public documentation and a pointer to the relevant hub (install, promos, VIP, code, support itself).
What the escalation path looks like:
- First reply. The first-line desk reads the ticket body and either resolves on the same reply or attaches the snapshot timestamp and the field that disagrees.
- Second-line desk. If the ticket is on the verified surface and the first-line desk cannot resolve it, the ticket moves to the second-line desk with the backend state already attached. The response window is still 24 hours on weekdays.
- Closure. When the ticket is resolved, the desk closes it on the backend and the user sees the resolution on the same ticket ID; the bonus card or the install hint reflects the change on the next refresh.
Channel, escalation and source of truth
The Come support desk keeps a single source of truth for ticket resolution. Verified: every channel points at the same backend snapshot the app reads on first launch, so a ticket answered on one channel reads the same answer on every other channel. Unverified: third-party channels that bypass the snapshot cannot resolve tickets against the verified surface and are closed with a pointer to the public documentation.
What the snapshot covers
The snapshot is the small set of fields the support desk and the app agree on at request time. Verified: the snapshot includes the install route, KYC state, payout route, VIP tier, self-limit tier, the wallet bonus card state and the most recent deposit and withdraw timestamps. Unverified: anything not on the snapshot - match data, side-game outcomes, chat activity, third-party offers - falls outside the verified surface and is closed with the public documentation.
The snapshot is read at request time on every ticket, so a field that changed on the app between ticket open and ticket reply is reflected on the reply. The reply names the field, the timestamp and the source field on the backend; that triple is what the support desk and the user agree on for the resolution.
How ticket replies cite the snapshot
Every ticket reply on the verified surface cites the field, the value, the source field and the timestamp. Verified: the format is stable across replies, so a user reading two replies can tell at a glance whether the fields agree. Unverified: replies that omit the timestamp are replies that fall outside the snapshot - those replies point to the public documentation and close the ticket rather than resolve against the snapshot.
How a typical reply is structured:
- Field name. The field on the snapshot (install route, KYC state, payout route, VIP tier, self-limit tier, bonus card state, deposit timestamp, withdraw timestamp).
- Current value. The value the backend read at request time, written as a single line.
- Source field. The backend table the support desk read the value from, named in the same wording the app uses on the relevant surface.
- Timestamp. The exact time the support desk read the value, down to the minute. If the user replies with a value taken at a different time, the support desk re-reads the snapshot before answering again.
When the desk is closed and how that is communicated
The Come support desk publishes a weekday response window of 24 hours. Verified: weekend response windows vary by ticket volume; the published window is on the support desk itself, not on a third-party calendar. Unverified: a reply sent outside the published window is a follow-up to an existing ticket, not a new ticket, and is treated as the same ticket ID for resolution purposes.
How the desk communicates a closed status:
- Field on the snapshot disagrees. The reply names the field and asks for the timestamp the user read. The reply does not invent a fix; it points to the surface the user can verify on the app.
- Field is outside the snapshot. The reply names the surface (match data, side-game outcomes, chat activity, third-party offers) and closes the ticket with the public documentation link.
- Field is on the snapshot and matches. The reply confirms the field and closes the ticket with the resolution timestamp. The user sees the resolution on the same ticket ID; the bonus card or install hint reflects the change on the next refresh.
If a ticket sits longer than the response window. Open a follow-up on the same ticket ID with the timestamp on the original ticket and the timestamp on the field that disagrees. The desk re-reads the snapshot at the second timestamp and replies against the current value, not the value at the first timestamp.