Opinion · An editorial recommendation
Find out what the request changes
“Quick question” can mean anything from finding a report to changing who can see payroll. The time it takes to ask tells you very little about the work needed to answer safely.
Start with the outcome the person needs. Ask what they are trying to do, who is affected and when the result matters. A request for administrator access may turn out to be a request to install one approved application. Understanding that distinction can make the answer both quicker and more appropriate.
Separate advice from an action
Explaining where a setting lives is different from changing it. Before making a change, identify the target environment, the people affected and whether the requester can authorise it. A helpful conversation should not quietly become an unrecorded production change.
For example, consider a fictional request to “just update the email address on the integration”. That address might also receive failure alerts, be used for account recovery or belong to a departing employee. Check its uses before replacing it, then agree how to prove the integration still works.
Ask questions that reduce uncertainty
Use plain questions: “Which system is this in?”, “Is anyone unable to work?”, “What deadline are we working towards?” and “Who else uses the same setting?” Explain why the answers matter. You are trying to avoid solving a different problem from the one the person has.
If you need logs or screenshots, ask for the minimum relevant detail through an approved channel. Do not ask someone to send a password, recovery code or an unrestricted export simply because it would make diagnosis convenient.
Give a useful next step
When the work needs a change window, say what happens before that window can be booked. Name the person who will assess the impact, the information still required and when the requester can expect an update. “Raise a ticket” is more helpful when you explain what to include and why a record is needed.
A response might be: “I can investigate today. Before changing that address, I need to confirm its recovery and alerting roles with the service owner. I’ll update the request tomorrow with a proposed window and checks.” Only promise dates you can support.
Keep urgent work proportionate
If a service is failing, use the organisation’s incident and emergency-change arrangements. Capture the essential facts while acting: what changed, who authorised it, how to check the result and what to do if it makes things worse. Complete the fuller record afterwards as the agreed process requires.
For routine questions, use a lighter response. A navigation tip should not need the same treatment as a permission change. The judgment is about impact and uncertainty, rather than making every request follow the longest possible process.
Watch for the question that keeps returning
When several people ask the same thing, keep a count and look at why they needed help. The answer may belong in the interface, onboarding material or a service request form. A reusable explanation can remove work for the requester as well as the support team.
Try this on the next request: clarify the outcome, decide whether it is advice or a change, and finish with a named next action. The person should know what will happen, even if the answer cannot be immediate.
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.