# Built In Support Tickets with Account Context | Vodlix **Source:** https://vodlix.com/features/built-in-ticket-support **Summary:** Support requests raised from inside the service arrive attached to an account, with plan, devices, sessions and orders beside the message rather than three lookups away. **Publisher:** Vodlix --- ## Built In Ticket Support A question raised from inside the product arrives already knowing who the person is, what they pay for and what their devices have been doing. - **Feature Plan:** 2 - back-end ## Half of Support Is Working Out Who You Are Talking To A support request that starts inside the service arrives attached to an account, which removes the exchange of emails that establishes identity before anybody has addressed the actual problem. ### The First Three Replies Are Usually Wasted Watch a typical streaming support conversation that began as an email and the shape is always the same. Somebody writes in saying it will not play. You reply asking which account, which device and which title. They answer some of that. You ask for the rest. Only then does anybody begin looking at the actual problem, by which point a day has passed and the viewer has formed a view about your service. None of those exchanges added information the platform did not already hold. They existed because the conversation started somewhere the platform could not see, and the entire argument for support that lives inside the product is that it starts from a person the system already recognises. #### Raised from inside The viewer is already signed in, so who they are and what they are entitled to arrives with the question rather than being established afterwards. #### Answered with the account in view Plan, devices, recent sessions and orders sit alongside the message, so the first reply can be about the problem rather than about identification. #### Kept with the account The thread stays attached, so the next person to pick it up does not restart a conversation the customer has already had once. ### The Context Is Already There What makes support on a streaming platform tractable is that the answers to the common questions are recorded rather than reported. Somebody says it will not play on their television, and the session log shows whether that device reached you at all. Somebody says they were charged twice, and the orders show what was taken and when. Somebody says they cannot sign in, and the locked addresses list shows whether they have been trying. In each case the platform knows before the customer explains, and the value of keeping support close to the platform is that this context is beside the message rather than behind three lookups. The underlying records are described under [user management](/features/user-management), [device management](/features/device-management-system) and the [orders manager](/features/orders-manager). ### The Best Ticket Is the One Nobody Raises It is worth being honest that most support volume on a subscription service is not really a support problem. It is somebody asking what a charge was, or when their plan renews, or why a title disappeared, and all of those are questions the platform can answer without a person. Every one of them that a subscriber can resolve by looking at their own account is a ticket that never arrives, which is a better outcome for both parties than handling it quickly. That is why billing history and viewing activity being visible to the viewer matters commercially rather than only as a courtesy, and it is covered under [billing management](/features/billing-management) and [continue watching](/features/continue-watch). ### Where a Dedicated Help Desk Still Wins Support inside the platform suits a team handling a manageable volume where the questions are mostly about accounts and playback. Past a certain size, or once you have a rota, service level commitments and multiple channels, a dedicated help desk does things a platform feature reasonably should not try to. The sensible pattern then is not to replace one with the other but to connect them, so tickets live where your team works and the account context follows through the API rather than being retyped. That route is described under the [REST API](/features/restful-api), and it is worth deciding which model you are in before committing, because moving later is more disruptive than choosing correctly at the start. **Q: Why raise support inside the product rather than by email?** Because an email starts from nothing and the first three replies are usually spent establishing who the person is and what they were doing. A request raised while signed in arrives with that already attached. **Q: What context does the team see?** The account and what it is entitled to, alongside the records that answer the common questions, which are the sessions for playback problems and the orders for billing ones. The first reply can then be about the problem itself. **Q: Does a thread stay with the account?** Yes, which matters when a conversation passes between people. A customer repeating themselves because the next person started from nothing is the most common complaint about support, and it is entirely avoidable. **Q: How do I reduce support volume rather than handle it faster?** Make the answers visible. Most enquiries are somebody asking what a charge was or when a plan renews, and every one a subscriber can resolve by looking at their own account is a ticket that never arrives. **Q: Can I use my own help desk instead?** Yes, and past a certain scale you probably should. The sensible pattern is to connect the two so tickets live where your team works while the account context follows through the API rather than being retyped by an agent. **Q: What are the most common support requests on a streaming service?** Billing questions, playback on one particular device, and sign in problems. All three have factual answers already recorded in the platform, which is why keeping support close to those records shortens them so much. **Q: Can support see what a viewer was actually doing?** The session and order records show what reached the platform and what was charged, which is usually the difference between a fault and a misunderstanding. Signing in as the viewer to reproduce something is available separately for the cases that need it. **Q: When should I move to a dedicated help desk?** When you have a rota, service level commitments or multiple channels to manage. Deciding that before you commit is worth the thought, because moving support tooling later is more disruptive than choosing correctly at the outset.