Support & IT

Support & IT — questions and answers

What's the difference between first-line, second-line, and third-line support?

First-line support handles common, well-documented issues: password resets, account access, basic troubleshooting. Second-line tackles more complex problems requiring deeper technical knowledge, like investigating application errors or server configuration issues. Third-line involves specialists or developers who work on the underlying codebase, infrastructure, or architecture when an issue can't be resolved through configuration or standard procedures.

How do support tickets get prioritised when everything feels urgent?

Prioritisation typically combines impact and urgency: how many users are affected, whether the system is completely down or merely inconvenient, and whether there's a workaround. A total outage affecting all users takes precedence over a single user's feature request. Many teams use severity levels—critical, high, medium, low—defined by specific criteria rather than requester preference, preventing everything from being marked urgent.

Why does fixing one issue sometimes break something else that was working fine?

Systems often have hidden dependencies: changing a server setting to fix one problem might affect another service relying on that configuration. A software update might introduce incompatibilities with existing plugins or integrations. This is why proper support work includes testing changes in a staging environment, maintaining rollback procedures, and documenting what was changed so unexpected side effects can be traced back to their source.

What information should someone provide when reporting a technical problem?

Effective problem reports include what the person was trying to do, what actually happened, exact error messages (not paraphrased), when the issue started, and whether it's consistent or intermittent. Screenshots, browser console logs, or steps to reproduce the problem help immensely. Vague descriptions like "it's broken" or "it doesn't work" force support staff to spend time extracting basic information before actual troubleshooting begins.

When a website or application goes down, what's the typical process for getting it back up?

The immediate priority is determining scope: is it completely down, partially functional, or affecting specific users? Check server status, recent deployments, and error logs. If a recent change caused it, rolling back is often fastest. Otherwise, isolate the failing component—database, web server, network, third-party service—and address that specifically. Communication matters: users need to know the issue is acknowledged and being worked on.

How often should backups be tested, and what does testing actually involve?

Backups should be tested regularly—monthly at minimum for critical systems—because discovering a backup is corrupted or incomplete during an actual emergency is catastrophic. Testing means actually restoring the backup to a separate environment and verifying the data is complete and the system functions properly. Automated backups that run successfully don't guarantee the backup files themselves are usable when needed.