When a computer, website, network, or business application fails, take a few minutes to document an IT problem before asking for help. Clear evidence gives a technician a starting point and reduces guesswork.
A useful report does not need complicated tools. It needs accurate observations, a simple timeline, and enough context to repeat the failure. The goal is not to diagnose the cause yourself. Instead, preserve what happened before a restart, setting change, or workaround removes useful clues.
Start to document an IT problem with the exact error
Copy the full error message whenever possible. Do not rely on a summary such as “the system is broken” or “the login failed.” Exact wording can identify whether the failure involves authentication, permissions, connectivity, storage, or an application process.
Record error codes, reference numbers, URLs, affected files, and the name of the application. If the message includes a timestamp, include it. Preserve capitalization and punctuation when you copy the text manually.
- Write down what you expected to happen.
- Record what happened instead.
- Note whether the error appeared once or repeatedly.
- Capture any code, message, hostname, account, or transaction reference.
- State whether the failure blocks work or affects only one feature.
A screenshot helps, but it should support the written description rather than replace it. Some screenshots omit text, hide the browser address, or capture only part of a dialog. Include the complete message in your notes when practical.
Build a timeline to document an IT problem accurately
Time information lets support compare your report with system logs. Record the date, local time, and time zone. If several people report the same symptom, note each observation separately.
For example, “At 9:42 a.m. Eastern time, the accounting application displayed ‘connection unavailable’ when opening an invoice” is more useful than “the application stopped this morning.” Add the first time you noticed the issue and the latest known occurrence.
Also note how long the problem lasted. Did it continue for ten minutes, disappear after a retry, or remain active? If the issue is intermittent, record several examples instead of only the most recent event.
Be careful with clock differences. A workstation, server, firewall, and cloud service may display different times. A technician can reconcile those differences more easily when your report identifies the clock and time zone.
Capture screenshots and other evidence safely
Use screenshots to show the visible symptom, but check them for sensitive information first. Redact passwords, access tokens, private customer data, payment details, and personal information. Never send a password as part of an IT support request.
Capture the screen before dismissing the message. Include enough surrounding context to show the application, account type, page, or device involved. For a browser problem, the address bar may matter. For a network issue, the device name or connection indicator may matter.
Name files consistently. A useful filename might include the date, time, device, and sequence number, such as 2026-09-14_0942-laptop01-error-01.png. Your actual date format can differ, but consistency helps everyone match evidence to the timeline.
Keep original files when possible. Cropping can help readability, yet it may remove details that later prove important. If you edit an image, retain the original and label the edited copy.
Consider logs and exported details
Some applications provide diagnostic logs, job histories, or exportable error details. Save those files without changing their contents. Record where each file came from and the time you exported it.
Do not delete logs, clear browser data, uninstall software, or run cleanup utilities merely to make the problem disappear. Those actions can remove evidence. A technician may recommend them later, after collecting the relevant information.
List affected users, devices, and scope
Scope often separates a local problem from a shared service problem. State whether one person, one device, one department, or everyone is affected.
- User or role affected, without sharing credentials.
- Device name, asset label, or a safe identifying description.
- Operating system and application name.
- Location, office, network, or connection type.
- Whether other users can complete the same task.
- Whether the issue affects computers, phones, websites, email, or servers.
To document an IT problem well, compare a working example with a failing example when you can do so safely. For instance, note whether another employee can open the same shared file or sign in to the same service. Avoid changing accounts or permissions just to test a theory.
Scope also includes business impact. Explain the task that cannot be completed, the number of people waiting, and any deadline. A failed report export may require a different response from a minor display issue, even when both show an error.
For connection symptoms, record whether the device uses wired Ethernet, Wi-Fi, a VPN, or a mobile connection. These details help support choose the right diagnostic path. Our network troubleshooting service focuses on this kind of evidence-led isolation.
Record recent changes before troubleshooting
Write down anything that changed before the issue appeared. Include software updates, password changes, new equipment, firewall adjustments, browser extensions, account changes, office moves, and provider work.
“Nothing changed” can still be a useful statement when you have checked the obvious sources. However, avoid assuming that a change caused the failure. Record timing and let testing establish the relationship.
- What changed?
- Who made the change?
- When did it happen?
- Which users or devices received it?
- Did the problem begin immediately or later?
- Was anything rolled back or changed again?
Include attempted fixes as well. A restart, password reset, reinstall, configuration edit, or network cable swap may alter the symptoms. Note the action, its time, and the result. This prevents support from repeating a step that already failed or overlooking a change that needs review.
Google’s effective troubleshooting guidance emphasizes evidence, hypotheses, and controlled tests. That approach works for small offices too: record observations first, then test one reasonable possibility at a time.
Describe reliable reproduction steps
Reproduction steps explain how someone else can see the same failure. Use numbered actions and include the starting point. “Open the program” is less useful than “Open the program, select Reports, choose Monthly Sales, and select Export.”
- Identify the device and account type used.
- Open the application, website, or file.
- Select the relevant menu, button, or link.
- Enter only safe test information.
- Record the exact point where the result differs.
State whether the problem happens every time. If it does not, estimate the frequency and describe what seems different. Mention whether the failure occurs after a specific delay, action, location change, or connection type.
Do not repeatedly reproduce a failure that could send duplicate orders, delete data, lock an account, or interrupt a production service. Ask for a safe test method when the consequence is unclear. Evidence should help recovery, not create a second incident.
Package the report for a fast response
Put the information into a short support request with a descriptive subject. Include the affected service, scope, business impact, and current status. Attach screenshots and logs through an approved channel. A concise package helps document an IT problem without burying the key facts in a long narrative.
A practical format looks like this:
Summary: Staff cannot export the monthly sales report.
First noticed: September 14, 2026, at 9:42 a.m. Eastern time.
Scope: Three users on two office computers; one user can still view the report.
Exact error: “[paste the complete message]”
Recent changes: Reporting application update installed September 13.
Steps: [numbered reproduction steps]
Attempts: Restarted one computer; same result.
Impact: Report is needed for the 11:00 a.m. review.
Attachments: Screenshot and exported diagnostic file.
Keep the first message focused. Add extra context below the core facts rather than burying the error inside a long narrative. If the issue changes, reply with new timestamps and results instead of editing history without explanation.
Before sending, verify that attachments open, times include a time zone, and sensitive data is removed. Confirm the best callback method and identify someone who can test a proposed fix.
Know when to stop collecting evidence
Documentation should not delay urgent action. If you suspect a security breach, active data loss, electrical danger, or a service outage with major business impact, follow your emergency procedure first. Preserve evidence where safe, but do not wait for a perfect report.
For ordinary failures, a concise record usually provides enough context for the next step. Avoid making several unrelated changes while waiting for support. Each change can alter the symptoms and make the cause harder to identify.
A clear report does not guarantee an immediate diagnosis. It does, however, give a technician a reliable starting point. When a problem affects multiple systems or needs log access, Tech Rescue Ops LLC can provide remote assistance after reviewing the available evidence. See the remote support process to understand when outside help may fit.