How to Collect a Screen Recording from a Customer

A customer writes, “Export failed again.” The error disappeared before they could copy it. Support cannot reproduce the problem, and a live call would mean comparing calendars across three time zones. A screen recording could settle the sequence in under a minute, but only if the request tells the customer what to show and what to keep out of view.

The useful request is not “send us a video.” It defines the start point, the action, the expected result, the safe capture boundary, and a fallback for anyone who cannot or does not want to record. The customer should be able to preview the result, re-record it, and submit only when it is safe to share.

Quick answer: how should support collect a screen recording from a customer?

First decide whether the issue needs motion. Use a screenshot or pasted error when one static state answers the question. Request a short video when order, timing, cursor movement, navigation, or a disappearing state matters. Write a specific prompt, tell the customer how to prepare the screen, and explain what not to include. Give them a screenshot or text alternative.

Send the request through an approved workflow such as Zight Request Video. The customer can respond in the browser without a Zight account or software installation. They should review the capture before submitting it and re-record if it contains private or unrelated information. If recording permission is blocked or the issue will not reproduce, collect the best available evidence instead of forcing the video path. Configure and disclose optional diagnostic-log collection separately.

1. Define the single troubleshooting question the recording should answer.
2. Choose screenshot, pasted text, or video based on whether sequence matters.
3. Prepare a copy-ready request with a clear start point and stop point.
4. Tell the customer to close unrelated windows and avoid sensitive information.
5. Send an approved request link; do not invent or guess a customer-facing URL.
6. Let the customer preview, re-record, or choose an alternative before submission.
7. Troubleshoot browser or operating-system permission blocks without asking for unsafe workarounds.
8. Collect logs only when configured, necessary, disclosed, and allowed.
9. Summarize the evidence in the ticket and retain it under policy.

Start with the question, not the record button

A screen recording should answer one question. “What happens between choosing Export and seeing the error?” is focused. “Can you show us everything you did today?” is not. The narrower request is easier for the customer, safer to capture, and faster for the agent to review.

Write down the expected behavior and observed behavior before sending anything. Expected: selecting Export downloads a CSV. Observed: the progress indicator stops and a temporary error appears. That gap tells you what evidence matters. The video may need the selected report, the export action, the waiting period, and the error. It probably does not need the customer’s inbox, billing page, team directory, or full desktop.

If support does not know what it needs to see, pause and ask a clarifying question first. A vague recording request transfers the diagnostic work to the customer and often returns a long video that still misses the failure.

Screenshot or video: choose the smallest useful evidence

A customer should not have to record motion when one image or a line of text will do. Use this decision table before you send the request.

When a still image is enough, use a structured Request Image workflow or ask for pasted error text. When the sequence matters, use Request Video. Give both options in the same message when you are unsure.

What the sender should set up before contacting the customer

The support agent owns the request design. Before sending the link, choose the workspace or queue where the response belongs, write the prompt, decide who can review the submission, and check the relevant request allowance and controls for the team’s plan. Test the request as an outside recipient instead of assuming the internal preview tells the whole story.

Set an expiration or closure practice if your workflow supports one, and connect the request to the ticket so the evidence is not separated from the question. Do not paste a made-up example URL into a macro. Create the request through the approved product flow and send the link it generates.

• One ticket and one troubleshooting question per request.
• A short title that describes the task, not the customer.
• Instructions with a start screen, action, stop point, and expected result.
• A safe-capture note about notifications, passwords, personal data, and unrelated tabs.
• A screenshot, text, or live-support alternative.
• Known reviewer access and a retention category.
• Diagnostic logs disabled unless the request specifically needs them and they are configured with notice.

Copy-ready request for a fictional export error

This message is original copy for a fictional product and synthetic report. Replace the bracketed support details and adapt the preparation guidance to your policy. Do not copy real customer values into the template.

Sender workflow: create, test, send, and stay responsible

For a complete team workflow, use the Zight customer support use case to connect request, diagnosis, response, and reusable documentation.

Create the video request in the team’s approved Zight workspace, add the customer-facing prompt, and copy the generated request link into the ticket, email, or chat. Zight’s current Request Video workflow is designed so the recipient can open the link in a browser, record, and submit without creating a Zight account or installing software.

That removes two common barriers, but it does not remove the sender’s responsibilities. Test the exact request from outside the workspace. Check whether the prompt is readable, whether the right response type is requested, what notice appears, where the submission returns, and who can access it. Browser, device, organization policy, and plan configuration can still affect the experience.

Keep the ticket open while waiting for evidence and give the customer a way to continue without it. A recording request is a support step, not a condition for receiving help.

Recipient workflow: prepare, record, preview, re-record, submit

The customer’s path should be predictable. First they read the prompt and decide whether the requested scope is acceptable. Next they prepare the screen: close unrelated apps, pause notifications, switch to sample data when possible, and place the relevant window where it can be captured clearly. They then follow the browser’s screen-sharing prompt and choose only the needed tab, window, or screen when that choice is available.

During the recording, the customer performs the requested sequence once. They can narrate the expected and actual result, but narration should never include credentials or private identifiers. The pointer should move slowly enough to follow, and the recording should stop as soon as the relevant result appears.

Before submission, the customer previews the entire capture. They check the beginning, transitions, corners of the screen, notifications, tabs, audio, and the final frame. If anything private appears or the sequence is missing, they re-record. They submit only the version they intend to share. Exact controls can vary, so the prompt should describe the decision rather than depend on a brittle button-by-button script.

1. Read the request and choose video or the offered alternative.
2. Prepare a clean, narrow capture area.
3. Allow capture only for the intended tab, window, or display.
4. Record one focused attempt.
5. Preview the full result.
6. Re-record if the evidence is incomplete or exposes unrelated information.
7. Submit the approved version and return to the ticket for next steps.

Handle screen-recording permission problems without unsafe workarounds

Browsers and operating systems may require permission before a site can capture a tab, window, display, microphone, or camera. Company-managed devices may block capture entirely. The wording and location of those controls differ by browser, operating system, version, and policy, so avoid claiming one universal path.

Ask the customer to read the visible permission message and choose only the source needed for the request. If permission was previously denied, they may need to review the browser’s site permission or the operating system’s screen-recording privacy setting, then restart the browser or capture flow. Give instructions for the customer’s actual environment or point them to the platform owner. Do not ask them to disable security software, remove device management, grant administrator rights, or weaken policy controls.

If the device is managed, the customer may need their IT team. If the customer is uncomfortable changing a permission, switch to a screenshot, pasted error, written reproduction steps, or an approved live session. The support outcome matters more than completing the recording.

What to do when the customer cannot reproduce the issue

Do not ask the customer to keep trying until the problem returns. Repeated attempts can change data, create duplicate actions, or make a customer feel responsible for proving the problem. Capture what is known while the details are fresh.

Ask for the last occurrence time with time zone, the exact task, account role, browser or app version, affected item type, error text, and whether anything changed afterward. A recording of the current normal state can help only if the contrast is useful; label it as “current behavior,” not a reproduction.

Support can then check approved logs or telemetry, compare recent changes, search for similar cases, or create a controlled test. If the issue is intermittent, send a prepared request the customer can use when it happens again, but give them a clear expiration and privacy reminder. Do not leave an open-ended capture link circulating without ownership.

Optional diagnostic logs need configuration, necessity, and notice

A recording shows the user-visible sequence. Technical troubleshooting may also need browser, operating-system, screen, console, or network context. Zight supports a configured Request Video with Data Logs workflow, but log collection is not a casual add-on to every request.

Before enabling it, decide which issues justify the additional evidence, which workspace administrators can configure it, who can review the returned data, and how long it is retained. Tell the recipient that technical context will be collected and explain its purpose. Follow company policy and applicable legal or contractual requirements.

Collect only what the investigation needs. Logs can reveal internal endpoints, request metadata, error details, identifiers, or other technical context even when the visible recording looks clean. Do not ask a customer to open developer tools or expose tokens and credentials when the configured collection flow is not approved. If the required notice or controls are missing, use the ordinary video request and another authorized diagnostic path.

• The issue requires technical context beyond the visible screen.
• The feature is configured by an authorized workspace administrator.
• The customer receives clear notice before recording.
• Review access is limited to the support or engineering roles that need it.
• Retention and deletion follow the evidence policy.
• The team has tested the request and review experience before using it with customers.

Review the submission before forwarding or diagnosing

The receiving agent should watch the complete recording before adding viewers or sending it to engineering. Check that it answers the stated question and does not contain unrelated private material. Look beyond the center of the screen: tabs, title bars, notifications, bookmarks, filenames, taskbars, background windows, audio, and transitions can reveal more than the customer intended.

Write the useful facts into the ticket. Record the expected behavior, observed behavior, timestamp, environment, account role, exact error, and the shortest reproduction sequence. The video is evidence; the ticket remains the case record. A teammate should understand the issue before clicking play.

If sensitive information appears unexpectedly, stop distribution and use the organization’s incident, access, and removal process. Do not assume deleting a ticket link removes every copy. Ask for a clean re-recording only when it is necessary and safe.

Turn the response into a useful escalation packet

Engineering should not receive a bare video link with “customer issue” in the subject. Package the evidence around one unresolved question. Include the ticket ID, impact, affected workflow, environment, role, expected result, observed result, timestamps, shortest known path, attempts already made, and the specific help needed from the receiving team.

Separate facts from theories. “The error appeared 18 seconds after Export in browser version X” is observable. “The network caused it” is a hypothesis until diagnostic evidence supports it. When optional logs are present, name the relevant console or network event without copying secrets into broad ticket fields.

Keep communication ownership with the support team unless the escalation process says otherwise. The customer should not have to chase engineering for status because they supplied a useful recording.

Retain recordings as evidence, not as permanent clutter

Apply the organization’s retention policy for support evidence, customer content, logs, and tickets. The right duration depends on policy, contract, investigation status, and legal obligations; it should not be invented by the agent. Record the category and owner so deletion or preservation is deliberate.

Restrict access to people working on the case or maintaining the approved support process. Remove access when roles change. If the resolution becomes reusable, recreate it with synthetic data and turn it into a maintained guide. Do not keep the customer’s recording forever just because it contains a good explanation.

When the retention period ends, use the approved deletion process and account for copies created during escalation or export. A link disappearing from the ticket is not proof that every retained copy is gone.

Common mistakes that produce weak or risky recordings

• Sending “please record your screen” without naming the exact task.
• Requesting a video when pasted error text or a screenshot would answer the question.
• Asking for the full desktop when one browser tab is enough.
• Failing to offer a non-video option.
• Assuming every browser, device, or managed environment handles permissions the same way.
• Telling the customer to disable security controls to make capture work.
• Requesting repeated reproduction attempts that could change data or create duplicate actions.
• Collecting diagnostic logs by default without configuration, necessity, and notice.
• Forwarding the link without a written summary and one clear escalation question.
• Keeping evidence indefinitely or outside the approved ticket and workspace.
• Claiming the workflow works identically on every platform or is available on every plan without checking current scope.

Support-team rollout checklist

• Define when agents should request text, screenshots, video, logs, or a live session.
• Create reviewed request templates for the top two or three recurring issues.
• Require a start point, stop point, safe-capture note, and fallback in every template.
• Test the recipient flow outside the company on representative browsers and devices.
• Document permission troubleshooting without universal platform claims.
• Confirm workspace, reviewer, integration, request allowance, and administrative scope for the current plan.
• Configure diagnostic logs separately and review recipient notice.
• Train agents to preview evidence before forwarding it.
• Keep expected and observed behavior in the ticket, not only in the video.
• Define retention, deletion, incident, and escalation owners.
• Sample completed requests after rollout and fix prompts that return irrelevant footage.

Frequently asked questions