Week 4

2.5 Understand the applications and processes of content management system (CMS) and the methods used to identify and resolve user problems

Content Management Systems and User Support Management

Applications and Processes of a Content Management System

A content management system, commonly known as a CMS, is a software platform used to create, organise, edit, publish and maintain digital content. Most CMS platforms are used to manage websites, intranets, online learning environments, knowledge bases and digital service portals.

A CMS allows users to manage content through a graphical interface rather than having to write all the underlying HTML, CSS or programming code. This means that staff with limited technical knowledge can update web pages, upload documents, publish news articles and manage multimedia content.

Common applications of a CMS include:

• creating and maintaining business websites

• publishing blogs, news articles and announcements

• managing e-commerce stores

• operating college or school learning platforms

• maintaining internal company intranets

• publishing technical support articles and user guides

• managing digital forms and online service requests

• controlling access to restricted content

• maintaining searchable knowledge bases

A typical CMS process begins when an authorised user signs in to the administration area. The user creates or edits content, adds images or documents, selects the correct page layout and submits the content for approval. Depending on the organisation, the content may be reviewed by an editor or manager before it is published.

Many CMS platforms use a content workflow such as:

1. Content is created.

2. The content is saved as a draft.

3. It is submitted for review.

4. An authorised user approves or rejects it.

5. The content is published.

6. The content is reviewed and updated when necessary.

7. Outdated content is archived or deleted.

These processes help organisations maintain accurate, consistent and professional content.

Examples of CMS Applications

WordPress

WordPress is a widely used CMS that can be used to create websites, blogs, online stores and membership platforms. It supports themes and plugins that add functions such as forms, e-commerce, security and search engine optimisation.

WordPress can also be extended with support-desk plugins. These allow users to submit support requests, receive ticket numbers and monitor responses.

Investigate the Wordpress environment by using the playground link below
WordPress Playground

Drupal

Drupal is a flexible CMS often used by large organisations, government departments and educational institutions. It provides detailed user permissions, content workflows and security controls.

Drupal can be configured to manage user requests, technical support content and internal knowledge bases. Modules can also be added to create ticketing and service-management functions.

Investigate the Drupal environment by using the playground link below
Try Drupal

Joomla

Joomla is used to create websites, online communities and company portals. It provides tools for content publishing, user access control and extensions.

Support-ticket extensions can be installed to allow users to report faults, request services and communicate with support teams.

Investigate the Joomla environment by using the playground link below
Softaculous - Joomla Demo

Microsoft SharePoint

Microsoft SharePoint is commonly used to create organisational intranets, document libraries, team sites and knowledge bases. It supports version control, approval processes, permissions and collaboration.

SharePoint can be connected to Microsoft Power Automate, Microsoft Forms and Microsoft Lists to create service request and incident-management systems. For example, a user could complete a support form, which automatically creates a ticket and sends it to the appropriate support team.

Moodle

Moodle is a learning management system that also includes many CMS features. It is used by schools, colleges and universities to publish learning content, assessments, announcements and support resources.

Users may report problems through Moodle messaging, support forms or integrated helpdesk systems. Administrators can use logs and activity reports to investigate user problems such as failed logins, missing course access or submission errors.

ServiceNow

ServiceNow is mainly an IT service-management platform rather than a traditional website CMS. However, it includes a self-service portal and knowledge-management system that allow organisations to publish support information and manage incidents, problems and requests.

Users can search help articles, report faults, request equipment and monitor their support tickets.

Zendesk

Zendesk is a customer-service and support platform. It includes a help centre that functions as a content management system for support articles, frequently asked questions and troubleshooting guidance.

Users can raise tickets through forms, email, web chat or telephone support. Support staff can categorise, prioritise, assign and resolve these tickets.

Methods Used to Identify User Problems

A user problem may be identified through direct reports, automated monitoring, system logs or patterns in support requests.

User Reports

Users may report that they cannot log in, access a page, upload a file, publish content or complete a form. The support team should collect accurate information about the problem, including:

• the username or account affected

• the device being used

• the web browser and version

• the page or service affected

• the time the problem occurred

• any error messages

• screenshots or screen recordings

• the steps taken before the problem occurred

This information helps the support team reproduce and diagnose the issue.

System Logs

CMS platforms normally record activity such as user logins, content changes, failed login attempts, permission errors and system events.

Logs can help identify:

• authentication failures

• unauthorised access attempts

• failed software updates

• database connection errors

• plugin or extension conflicts

• file-upload failures

• permission problems

• server errors

For example, if several users cannot upload files, the logs may show that the server storage is full or that the permitted file size has been exceeded.

Monitoring Tools

Monitoring software can identify problems before users report them. Monitoring may check:

• whether the website is available

• page response times

• server memory and processor use

• database performance

• security threats

• storage capacity

• broken links

• failed backups

An alert can automatically notify the support team when a service becomes unavailable.

User Feedback

Surveys, feedback forms, helpdesk tickets and direct discussions can identify usability problems. A system may be working technically but may still be difficult for users to understand.

For example, users may repeatedly submit support tickets because the upload button is difficult to find. In this case, the problem may be resolved by redesigning the page rather than repairing the software.

Ticket Analysis

Support teams can review existing tickets to identify repeated incidents. If many users report the same problem, this may indicate a larger system issue.

For example, repeated password-reset requests may show that password guidance is unclear or that the authentication process is too complex.

Methods Used to Resolve User Problems

The method used to resolve a user problem depends on its cause, urgency and impact.

Reproducing the Problem

Support staff may attempt to repeat the user's actions. This helps confirm whether the problem is caused by the user's device, their account or the CMS itself.

Checking User Permissions

Many CMS problems are caused by incorrect access permissions. A user may be able to view a page but not edit it, or may be unable to access a restricted section.

Support staff should check the user's role, group membership and permissions before making changes.

Reviewing Recent Changes

A problem may have started after:

• a CMS update

• a plugin installation

• a theme change

• a server update

• a permissions change

• a database modification

Support staff may compare the time of the incident with recent system changes. If necessary, the change can be reversed or corrected.

Applying Updates and Patches

CMS providers regularly release software updates to correct security vulnerabilities, improve compatibility and repair faults. Updates should normally be tested before being applied to a live system.

Disabling Faulty Extensions

Third-party plugins, themes or modules can cause system conflicts. A support technician may temporarily disable extensions to identify the cause.

Restoring a Backup

If content has been deleted, corrupted or damaged, the organisation may restore the CMS from a recent backup. The support team must check when the backup was created because changes made after that point may be lost.

Providing User Guidance

Some reported problems are caused by a lack of knowledge rather than a technical fault. In this situation, the support team may provide:

• step-by-step instructions

• screenshots

• video demonstrations

• knowledge-base articles

• remote support

• staff training

Escalating the Issue

If first-line support cannot resolve the problem, the ticket may be escalated to a specialist, system administrator, developer or external supplier.

Escalation should include all relevant information so that the user does not have to explain the problem again.

Problem, Incident and Request Management

CMS and support platforms may be used to manage problems, incidents and service requests. Although these terms are related, they have different meanings.

Incident Management

An incident is an unplanned interruption to a service or a reduction in the quality of a service.

Examples include:

• a CMS website is unavailable

• users cannot log in

• pages produce error messages

• uploaded files cannot be opened

• content has disappeared

• a publishing workflow has stopped

• a form is not submitting correctly

The main purpose of incident management is to restore normal service as quickly as possible.

An incident-management process may include:

1. The incident is reported or automatically detected.

2. A support ticket is created.

3. The incident is categorised.

4. Its impact and urgency are assessed.

5. A priority level is assigned.

6. The incident is investigated.

7. A temporary workaround may be provided.

8. The service is restored.

9. The ticket is updated and closed.

10. The resolution is recorded for future reference.

For example, if the college website is unavailable to all users, the incident would have a high impact and would normally receive a high priority.

Problem Management

A problem is the underlying cause of one or more incidents.

For example, users may repeatedly report that a CMS stops responding. Each individual report is an incident. An investigation may show that the underlying problem is insufficient server memory or a faulty plugin.

Problem management focuses on identifying and removing the root cause.

The process may include:

1. Reviewing related incidents.

2. Identifying patterns and trends.

3. Investigating the root cause.

4. Recording a known error.

5. Developing a workaround.

6. applying a permanent fix.

7. monitoring the system to confirm that the problem has been resolved.

Problem management is usually less focused on immediate restoration and more focused on preventing the incident from happening again.

A CMS knowledge base can support problem management by recording known errors, workarounds and permanent solutions.

Request Management

A service request is a request from a user for information, access or a standard service. It is not normally caused by a fault.

Examples include:

• requesting a new CMS user account

• asking for access to edit a website section

• requesting a password reset

• asking for a new course area in Moodle

• requesting a new SharePoint site

• asking for a page to be created

• requesting the installation of an approved plugin

• requesting training on how to publish content

Service requests are normally handled through a standard approval and fulfilment process.

For example, a request for website editing rights may require approval from a department manager before the support team changes the user's permissions.

How CMS and Support Tools Manage Incidents, Problems and Requests

CMS and service-management tools normally use forms, workflows, databases and notifications to manage support work.

When a user submits a request, the system may automatically:

• create a unique ticket number

• record the date and time

• identify the user

• assign a category

• set a priority

• send a confirmation email

• assign the ticket to a support team

• apply a service-level target

• record all communication

• notify the user when the ticket changes

• close the ticket when the work is complete

Tools such as ServiceNow and Zendesk contain these functions as standard. Other CMS platforms, such as WordPress, Drupal and SharePoint, may require plugins, modules or workflow tools.

Logging and Raising Support Requests

Logging a support request means creating a formal record of the user's problem or request.

A support request may be raised through:

• an online helpdesk form

• email

• telephone

• live chat

• a self-service portal

• a chatbot

• face-to-face support

• automated system monitoring

The support record should include enough detail for the issue to be investigated.

Typical ticket information includes:

• ticket reference number

• user's name and contact details

• date and time reported

• description of the issue

• affected system

• category and subcategory

• impact

• urgency

• priority

• assigned technician or team

• current status

• attachments and screenshots

• actions already attempted

The support form should use clear questions to help users provide useful information. Drop-down menus can improve consistency by allowing users to select the affected system or problem category.

For example, a user may select:

System: Moodle
Category: Account access
Issue: Unable to access course
Impact: One user
Urgency: Medium

The system can then route the request to the Moodle support team.

Tracking Request Progress

Users and support staff need to be able to track the progress of a support request.

Common ticket statuses include:

• New

• Logged

• Assigned

• In progress

• Awaiting user information

• Awaiting approval

• Escalated

• On hold

• Resolved

• Closed

• Reopened

The ticket history should show every action taken. This may include comments, emails, status changes, reassignment and technical work.

For example:

• 09:10 — User submitted the request.

• 09:12 — Ticket automatically assigned to first-line support.

• 09:30 — Technician requested a screenshot.

• 10:05 — User uploaded the screenshot.

• 10:20 — Permission error identified.

• 10:30 — Access permissions corrected.

• 10:45 — User confirmed that access had been restored.

• 10:50 — Ticket marked as resolved.

Users may track progress through a self-service portal or receive automatic email notifications.

Tracking progress provides accountability because it shows who is responsible for the request and what action has been taken. It also helps managers identify tickets that have not been updated within the agreed service level.

Tracking Open and Closed Tickets

An open ticket is a ticket that still requires action. A closed ticket is a ticket that has been completed and formally ended.

Open-ticket reports may show:

• newly submitted tickets

• tickets awaiting assignment

• tickets currently being investigated

• tickets waiting for user information

• tickets that have exceeded their target time

• high-priority incidents

• tickets assigned to each technician

Tracking open tickets helps support teams manage their workload and prevent requests from being forgotten.

Closed-ticket records usually contain:

• the original issue

• the investigation completed

• the action taken

• the final resolution

• the date and time of closure

• the technician responsible

• confirmation from the user

• any related knowledge-base article

Closed tickets should be retained because they provide evidence of support activity and can help resolve similar issues in the future.

For example, when a new user reports a publishing error, a technician may search previously closed tickets and find that the same issue was caused by an incompatible browser extension.

A ticket may be marked as resolved before it is closed. Resolved means that a solution has been provided, while closed normally means that the user has confirmed the solution or that the agreed confirmation period has ended.

If the problem returns, some systems allow the user or technician to reopen the ticket.

Benefits of Using CMS and Ticket-Management Tools

Using a structured CMS and support-management system provides several benefits:

• user problems are recorded consistently

• support requests are less likely to be lost

• users can monitor progress

• support staff can prioritise urgent incidents

• requests can be assigned to the correct team

• managers can monitor workload and performance

• repeated problems can be identified

• previous solutions can be reused

• service-level targets can be measured

• support documentation can be published through a knowledge base

However, the system is only effective when staff keep tickets updated and users provide accurate information. Poor categorisation, incomplete descriptions or tickets being closed too early can reduce the quality of support.

A content management system allows organisations to create, organise, control and publish digital content. Platforms such as WordPress, Drupal, Joomla, SharePoint and Moodle support different types of website, learning and document-management activity.

CMS platforms can also be connected to helpdesk and service-management tools such as ServiceNow and Zendesk. These tools help organisations log incidents, investigate problems and fulfil user requests.

By logging support requests, tracking their progress and maintaining records of open and closed tickets, organisations can provide a more organised and accountable support service. Ticket histories, system logs, monitoring tools and knowledge-base articles also help technical staff identify recurring problems and develop permanent solutions.

• Knowledge management:

o identification of staff training needs (for example, use of particular software)

o collating of user support knowledge.

• Change management:

o supporting implementation of new systems.

• Configuration/asset management:

o tracking software licences

o responding to requests for hardware and software

o decommission or redeployment of systems/users.

• Methods used to identify and resolve user problems:

o troubleshooting to diagnose problems:

– information gathering:

       investigation of support requests

       investigation of probable causes

       troubleshoot issues (for example, check line speeds, check uptime and downtime) problem analysis:

       elimination of known fixes and problems

       elimination of potential causes

       consideration of remaining possibilities

– test remaining possibilities:

       testing and elimination of possible causes

       identify the appropriate solution

– problem resolution:

       backing up data on system

       implementing the solution

       testing the solution

       repeating the process until required outcome

       documenting the cause and solution on content management system

       implementing security controls to mitigate against cause reoccurring.

2.6 Understand the types of end user devices and systems where content management systems can be applied to identify and resolve user problems

• Desktop:

o thick clients

o thin clients.

• Cloud workspaces:

o free cloud workspaces

o paid licensed cloud workspaces.

• Mobile devices:

o tablets

o smartphones

o wearable technology (for example, smartwatches)

o e-reader.

• Laptops.

• Peripherals:

o mouse

o keyboard

o monitors

o printers/scanners

o speakers

o projectors

o storage drives

o magnetic reader/chip reader

o smart card reader.

• IoT:

o smart buildings:

– alarm systems (for example, fire, security)

– metres (for example, water, power)

– lighting

o smart devices:

– autonomous vehicles

– TVs.

Last Updated
2026-07-13 10:21:56