A useful brief starts with what your team experiences
You do not need to diagnose Magento before commissioning a performance investigation. You need to explain what feels wrong, where it happens and why it matters. “Customers wait a long time after selecting delivery” is more actionable than “the whole website needs optimisation”, because it identifies a journey that can be observed and compared.
Preparation should be proportionate. Start with the fields requested for your selected package and add optional information only where it helps. This guide is a way to organise useful evidence, not an extra compulsory questionnaire. It should reduce back-and-forth, not turn a straightforward purchase into a technical project for the customer.
Pick representative URLs and actions
Choose pages that reflect how people shop: a category customers use, a representative product and an important next action. If the problem involves filters, account state or a basket, describe those conditions alongside the URL. An investigator cannot reconstruct a private basket from the public checkout address alone.
Explain why each example matters. It may receive campaign traffic, represent a large category or reproduce a reported failure. Avoid sending hundreds of URLs without priorities. The package determines the agreed sample; a focused set is easier to investigate consistently than a list whose members all represent the same template. If you are unsure which examples fit, say so in the optional notes.
- 01ExplainOne clear account of the affected journey
- 02SelectRepresentative URLs and useful examples
- 03ShareRequested access through the secure portal
- 04ReviewA report with priorities and limitations
Describe timing without choosing a delivery date
Useful timing information concerns the symptom: when it started, whether it follows imports or releases, and when it is worst. Include the time zone for an observed incident. You do not need to invent an investigation delivery date. Published package timing and any written proposal establish the service schedule, subject to the stated starting conditions.
If a promotion creates a real business deadline, explain it as context. That does not automatically change a package's delivery terms or turn an ordinary investigation into a capacity test. For peak readiness work, the expected workload, environment and test limits need to be agreed. The package comparison explains the available routes.
Distinguish observations from suspicions
An observation is something you can describe or reproduce: a product grid takes noticeably longer after a filter selection, or an Admin save stalls during a scheduled import. A suspicion is a proposed explanation, such as an extension or hosting limit. Both can be useful, but label them separately so the investigation is not constrained by an unproven assumption.
Include what changed recently: application release, extension update, hosting migration, CDN rule, marketing tag or catalogue process. “Nothing changed” should mean no known change, not a certainty that every supplier and system stayed identical. A release identifier or short deployment note helps connect the symptom to evidence without requiring a complete technical history in the intake form.
Use a compact evidence brief
The following worksheet can be copied into your own notes. Complete the parts you know and leave unknown items clearly marked. Its purpose is to make the important facts easy to find. It is not a request to upload customer data, credentials or an unrestricted production database.
| Scope | Useful information | Access approach |
|---|---|---|
| Snapshot | Public store address and four useful public URLs. | Public assessment; do not send administrator credentials. |
| Full Investigation | Affected journeys, examples and recent relevant changes. | Only the access requested for the agreed investigation. |
| Peak Readiness | Traffic question, expected workload and business priorities. | Agreed staging environment and explicitly scoped test access. |
| Any scope | Optional context if it changes the investigation question. | Share sensitive details only through the agreed secure route. |
For example: “Guest shoppers on mobile can browse normally, but selecting delivery on a basket with two items pauses before payment options appear. First noticed after Tuesday's shipping-module release. It also happens outside our busiest period.” This fictional example provides a journey, conditions and a timeline without pretending to know the cause.
Provide competitor examples only when they are relevant
If public competitor comparison is included and you have useful examples, provide the URLs and say what you want to understand. Compare a similar page or journey where possible. A lightweight single-product page and a complex configurable-product page may have different requirements; the comparison needs context rather than a simple fastest-wins conclusion.
Public comparison cannot reveal a competitor's internal architecture, operating costs or conversion results. Do not ask your team to obtain private access or confidential information. The aim is to establish externally observable context for the agreed sample. The investigator should explain limitations instead of presenting a public measurement as proof of another business's internal performance.
Handle internal access when it is requested
Public assessment and internal investigation have different access needs. Do not send server credentials pre-emptively in ordinary messages. Use the portal's secure access workflow when access is requested, complete the fields relevant to your environment and add explanatory information where necessary. If a requested type of access is unavailable, say so; it may affect what can be established.
Where your organisation supports it, provide named, scoped and revocable access for the agreed work. Record who can approve access and how it will be removed afterwards. An infrastructure provider may need to help with logs or monitoring. Preparation is easier when responsibilities are clear, but access should not be broadened simply to avoid asking a specific question.
Share diagnostics without sharing unnecessary personal information
Logs, screenshots and browser recordings can contain names, email addresses, session identifiers, addresses or payment references. Before sharing, keep the evidence needed to explain the issue and remove unrelated personal or secret information. If redaction would remove essential diagnostic detail, agree a suitable secure method rather than pasting the complete file into email.
A screenshot of a slow spinner is useful for locating the step but rarely explains its cause. A timestamp and reproducible action add value. Do not run intrusive profiling or high-volume tests on production just to prepare for the investigation. Describe what monitoring already exists and let the agreed scope determine whether further collection is necessary.
Keep the store stable enough to compare
Avoid combining the investigation with several unrelated performance changes unless they are operationally necessary. If a deployment must happen, record it and tell the investigator. Otherwise, before-and-after evidence may describe different systems and the report may attribute a result to the wrong change. Emergency recovery always takes priority over preserving a perfect experiment.
Select one contact who can clarify business behaviour and identify the technical owner who can answer access or release questions. They can be different people. Agree where follow-up questions will be answered and check the investigation overview for outstanding tasks. A useful brief cannot prevent every question, but a clear response route keeps the work moving.
Plan what happens after the report
Decide who will attend the debrief and how recommendations will become an implementation backlog. Ask for findings to distinguish evidence, confidence, priority and acceptance criteria. The example report guide explains that structure. A report is more useful when the person authorising changes and the team implementing them share the same understanding.
If the store is currently down or payment outcomes are uncertain, use emergency support instead of waiting to assemble a perfect brief. Provide the essential facts first. For planned work, start with the Performance Investigation options, complete the requested intake and use optional notes for anything else that materially helps.
Common questions
Do I need to know my Magento version before asking for help?
Provide it if you know it. Do not guess. A technical contact can help establish the environment when the scope requires it. The customer-facing symptom remains the most useful starting point.
Should I send every log file and extension list?
No. Start with the requested information and relevant observations. Additional evidence can be requested through the appropriate secure route when its purpose is clear.
Is this guide adding mandatory steps before payment?
No. The selected service's intake determines the required fields. This optional guide helps you prepare concise, useful answers and understand later access requests.