# How to ask a customer to record a bug without another support call — Rill Source: https://userill.dev/blog/ask-customer-to-record-a-bug-without-a-support-call When a customer says “my cards disappeared,” ask for a recording of the steps that led there. Give them a clear place to start, a point to stop, and a way to keep private information out of the capture. You can then review the same sequence your customer saw before deciding what to investigate. In Rill, you can send a request link to someone outside your team. They record in their browser, preview the video, and send it without creating a Rill account. Here is a practical way to use that request: choose one question, ask for one attempt, then respond with what the recording established and what you still need. For your own team’s handoff after the clip arrives, see [How to report a bug with a screen recording](https://userill.dev/blog/how-to-report-a-bug-with-a-screen-recording). ## Start with the missing detail Read the conversation before asking the customer to do more work. You may already know which page they used, what they expected, and when the problem began. Keep those details with the request rather than asking for them again. Choose the question a video can answer. For “my cards disappeared,” it might be: what happens between using the board search and seeing fewer cards? That gives the customer a small flow to show. Use a recording when the order of actions, a loading state, or a change on the page matters. **When not to send a request:** If the customer cannot safely reproduce the issue, needs live help, or the only missing fact is text, such as an error message or browser version, ask for that directly or arrange a call. For urgent assistance, choose the quickest way to help. ## Write a request with a clear start and finish Each request link accepts one recording and expires after seven days. The recording arrives in your library. Open recording requests in Rill while signed in and describe what you need to see. Include the starting page or state, the actions that matter, and the outcome the customer should leave visible. A title such as “Board cards stay filtered after clearing search” is easier to recognize later than “Please record the issue.” Keep the ask short enough to follow while recording. For a simple interaction, aim for roughly 30 to 60 seconds. Longer is fine if loading is slow; this is a useful target, not a reason to cut off the result. Use this message as a starting point: Could you record one attempt at \[the problem\] using this link: \[recording request link\]? Start on \[page and starting state\], then \[specific actions\]. Stop after \[the result we need to see\] has been visible for a few seconds. Please use the browser where it happened. Use safe sample data if it still shows the same problem, and keep passwords, private records, and unrelated tabs out of the recording. Preview it before sending. You do not need a Rill account. If you cannot show the problem safely, or it does not happen this time, let us know. Alongside the recording, tell us \[only the missing context\]. Avoid asking the customer to clear their cache, switch browsers, or reset the app before capturing the original behavior. Those changes may alter the conditions you need to understand. If you later ask for a comparison, describe it as a separate attempt. ## Make the recording safe to send Ask the customer to sign in to the affected app before starting, unless the sign-in flow itself is the problem. They should choose the narrowest capture area their browser offers that still shows the relevant steps. Capture choices vary by browser. A safe sample record helps only if it preserves the behavior being reported. If the problem depends on private data, do not ask the customer to expose it just to complete the recording. Agree on a safer way to investigate. Before they begin, ask them to close unrelated windows and silence notifications. Rill does not mask sensitive content in the video. The preview is an opportunity to catch accidental exposure before sending. Tell the customer not to send it if the preview contains private information. Agree on a safer capture instead. A customer screen recording shows visible behavior, with optional microphone narration. It does not automatically collect console messages or network diagnostics. Keep the request focused on what the customer can show. ## A worked example from request to investigation This example is fictional. The app, customer messages, data, timestamps, and results are illustrative; no actual customer recording is attached. Suppose a customer reports that cards disappear from a project board after searching. In this fictional app, clearing the search should restore all six cards on the demo board. Support already knows the affected page and asks for the transition it has not seen. **The request** Could you show what happens when you clear the board search? Use this recording request: \[recording request link\]. On the Demo board, start with all six sample cards visible. Type “review” in Search, then clear the search using the × control. Leave the board visible for five seconds. If cards are still missing, reload once and show whether they return, then stop. Please use the same browser where you saw the issue and keep the sample card names visible. Do not open real client cards. Preview before sending. If the Demo board does not show the same problem, tell us rather than recording private records. In your reply, include your browser version and whether it happens every time or only sometimes. No need to investigate the cause. The reload is intentional here: it is a safe action on this sample board and answers a specific question about whether the cards reappear. For a form with unsaved work or a payment flow, choose different steps. **What the returned clip shows** 00:00: The Demo board contains six visible sample cards and an empty search field 00:06: The customer types “review”; two matching cards remain 00:12: The customer clicks × and the search field becomes empty 00:17: The board still shows only the same two cards 00:22: The customer reloads; all six cards appear Clearing the search does not restore the board; reloading does. That is consistent with a stuck filter, but the clip does not establish the cause or whether underlying data changed. Treat a stale filter as a hypothesis to check. The customer's accompanying reply says it happened twice in three attempts. That is a separate report about earlier attempts. The clip itself shows one failing attempt. **The note for the developer** Observed: In the attached recording, clearing Search at 00:12 leaves two cards visible through 00:17. Reloading at 00:22 restores all six. Expected: an empty search should show all six cards on this Demo board. Scope: One recorded attempt. The customer separately reports two failures in three attempts. This clip does not establish whether data was deleted or which part of the app caused the display state. Next check: Repeat the same search and clear sequence on a safe six-card board in the reported browser. Check whether clearing the visible field also resets the active filter. Treat a stale filter as a hypothesis until verified. Attach the clip and browser details to the existing issue. Identify any later diagnostic capture as a new attempt; do not attribute its console or network events to the customer’s video. ## Ask for the smallest useful follow up An inconclusive recording still tells you what to ask next. Describe the missing moment instead of sending the whole request again. If the clip ends as the customer clears the search, you could reply: I can see the search field clear, but the video stops before we can see the board settle. Could you make one more recording and leave the board visible for five seconds after clearing it? Here is a fresh request link: \[recording request link\]. Because each request accepts one recording, create a new request for another submission. If an unused link has expired, send a fresh one with the same focused instructions. If the clip shows the expected behavior, record that outcome and ask what differed from the earlier attempt. A successful attempt does not resolve an intermittent report. Start with one relevant difference, such as the browser, starting filter, or sample record, rather than asking the customer to try a long checklist. Once you have enough evidence, acknowledge exactly what you saw. In the fictional example: “Thanks, I can see the cards stay filtered after the search clears and return after reload. We have the steps we need to investigate.” Only send that commitment when it reflects what your team will do. ## Keep the recording with the support conversation Review the returned video for private information before giving it a wider audience. Share only with the people who need to investigate. Anyone with an active Rill share link can view the recording and its included content. Keep the clip, the customer's original description, and your evidence note together so the next person can see how the investigation developed. For the next customer report that needs visual context, create a recording request for one flow. Tell the customer where to start and stop, review what they send, and use that evidence to choose the next check. [Create a recording request](https://userill.dev/recording-requests) — sign in, describe one flow, and send the link.