The method
- Identify the equipment involved: model, operating system, software version and accessory. Record what is available without opening the hardware. Separate a product name from its exact reference, and leave the latter blank when it is unknown.
- Describe one reproducible situation: attempted action, expected outcome, observed outcome and exact message. Include what still works. A connection failing on one device and an outage affecting the whole home raise different questions; your note does not establish their cause.
- List changes preceding the problem and tests already performed, with their outcomes. Prepare a cropped screenshot when it clarifies the message, removing private identifiers. Send the note through your chosen support channel; avoid risky operations merely to fill a field.
Fictional worked example
In a fictional case, a computer shows a message when one file is opened, while other files open normally. The note records the application, file type and message, and marks another device as untested. This boundary prevents a local observation from becoming a claim about the whole computer.
The record to keep
Keep a dated version of the note and the replies received. Give each new attempt its own row so the initial observation remains distinguishable from later changes.
Your record, step by step
For your own situation, record the following information. Check a field when it is documented; missing information still needs verification. The boxes are a reminder within this page.
This checklist does not validate your project. No entries are sent or saved.
Fictional worked case. A fictional support request concerns a file opening on one computer but failing on another.
| Element | Observation in the case | Interpretation or next check |
|---|---|---|
| Context A | Application 4.2 on the first computer | Record version and system without private identifiers |
| Context B | Application 3.8 on the second | Version difference is a lead, not a proven cause |
| Symptom | Exact message copied after the same action | Separate the observed message from interpretation |
| Controlled trial | Same file copy in another compatible application | Keep the outcome, including no change |
What this method can establish
The note supports a precise question; it establishes neither a hardware fault nor replacement compatibility. Microsoft’s reference covers Windows. For another operating system, use its publisher’s documentation.
Useful questions before you start
Must all logs and folders be attached for precision?
No. Start with the symptom, steps and a useful excerpt. Review attachments to remove secrets, personal data and irrelevant details.
HTTPS protects a connection, not a commercial promise
HTTPS encrypts the connection to the requested server. It does not validate an offer, product or business identity claimed in page text.
- Read the server name
- Find the known channel
- Examine the requested action
| Situation | What changes | Useful check |
|---|---|---|
| Encrypted connection | Data is protected in transit. | Also check the domain and purpose of the request. |
| Familiar name in the path | A path can name a different organisation. | In https://example.invalid/bank, the server remains example.invalid. |
| Link received in a message | Link text can hide a different destination. | For a sensitive task, start from a known bookmark or official website. |
The .invalid address is a fictional example. The portal’s address reader parses syntax without visiting the site, so it cannot inspect redirects or actual content.
Documentation : Mozilla — HTTPS-Only Mode ↗ · · Read the reference record →
Supporting documentation
These references support the method. Each source shows its language and consultation date; an available directory record explains its purpose.
- Microsoft Support — Device information EN ↗
Documentation consulted on
An editorial method, a fictional example and references for further reading.