Skip to content
OTOBO Community Guide

States

OTOBO ticket states overview Efficient ticket management and monitoring their status play a crucial role in helpdesk management and customer support. OTOBO, the versatile ticket system, offers comprehensive functions for ticket status management to ensure a seamless workflow and improved customer relationships. Discover how you can effectively manage ticket statuses with OTOBO and optimize your service desk performance.

Optimizing Ticket Management

Section titled “Optimizing Ticket Management”

By actively monitoring the status of tickets, you gain valuable insights into your team’s workload and generate important Key Performance Indicators (KPIs). Prioritizing tasks and setting deadlines help balance the workload and ensure the continuous functionality of your service desk. OTOBO offers sophisticated solutions for this through the use of specific ticket statuses.

Definition - Ticket Status

Section titled “Definition - Ticket Status”

OTOBO uses predefined ticket statuses to clearly communicate the processing stage. This way, Agents always know which tickets require their attention. Additionally, OTOBO offers the ability to create detailed evaluations of ticket statuses via ticket search or special reports. Dashboards, queue overviews, and service overviews facilitate personalized sorting and provide a clear overview.

  • closed successful: A ticket has been successfully resolved.
  • closed unsuccessful: A ticket was closed without finding a solution.
  • merged: The content of the ticket has been integrated into another ticket.
  • new: The ticket was opened without agent contact.
  • open: Ticket in progress with active communication between Customers and the agent.
  • pending auto close (+/-): Tickets that are automatically closed as successful or unsuccessful based on the elapsed waiting time.
  • pending reminder: Tickets that are to be processed again after the waiting time.
  • removed: The ticket has been removed from the system.

Managing Ticket Statuses

Section titled “Managing Ticket Statuses”

Managing ticket statuses is a central aspect of the OTOBO platform. To add a new state, navigate to the States section in the Ticket Settings module. A fresh installation of OTOBO includes a set of states by default that ensure efficient ticket processing.

Adding a State

Section titled “Adding a State”

To add a new state, follow these steps:

  1. Select Add state in the menu.
  2. Fill in all required information.
  3. Save the new state.

Note that states cannot be deleted, only deactivated. This is done by setting the Validity to invalid or temporarily invalid.

Editing and Checking States

Section titled “Editing and Checking States”

Editing existing states is designed to be intuitive. Select a state from the list, make your adjustments, and save them. If you change the name of a state already used in the system configuration, OTOBO performs a validation check and warns of potential conflicts.

Effective management of ticket states is a key aspect of the success of any helpdesk or customer support system. OTOBO offers an advanced and flexible way to configure and customize ticket states to optimally support process handling in your service desk.

Options for Changing State Names

Section titled “Options for Changing State Names”

When you change the name of a state, OTOBO offers you three options:

  • Save and update automatically: This option applies the change and also automatically updates all affected settings. This facilitates the maintenance of the system configuration and ensures that all connections and references remain consistent.

  • Do not save, update manually: Choose this option to apply the changes without automatically updating the affected settings. You must then manually check all active connections and references and update them if necessary.

  • Cancel: This option cancels the process without making any changes. It is usually chosen when the impact of a name change is uncertain.

It is extremely important to handle the renaming of objects with caution, as not all links can be verified automatically. Special attention should be paid to dashboards, action control lists, and processes. Thorough documentation of your configuration is essential to mitigate this risk.

Settings for Managing States

Section titled “Settings for Managing States”

When configuring or editing a state in the ticket system, the following fields should be noted:

  • Name: The unique name of the state, which is visible in overviews.
  • State type: Specifies the type of state, e.g., closed, new, open, pending, etc.
  • Validity: Determines whether the state is active (valid) or deactivated (invalid or temporarily invalid).
  • Comment: Provides space for additional explanations or notes regarding the purpose or use of the state.

Important Configuration Options

Section titled “Important Configuration Options”

To adjust the behavior of pending tickets and their verification, special system configuration options are available in OTOBO:

  • Daemon::SchedulerCronTaskManager::Task###TicketPendingCheck: This configuration controls the frequency with which the system checks the status of pending tickets. It is crucial for the efficiency of the reminder system and the automation of ticket processing.

  • Ticket::StateAfterPending: Determines the state a ticket changes to after the pending deadline has expired. This setting allows workflows to continue seamlessly after waiting for a response or the completion of tasks.

The customization and configuration of ticket states in OTOBO provides a flexible foundation for a powerful ticket system. A well-thought-out implementation of these functions can significantly improve the efficiency and responsiveness of your service desk.

Status Evaluation in Statistics

Section titled “Status Evaluation in Statistics”

Evaluating ticket statuses in OTOBO allows you to analyze the performance of your service desk and gain important insights. By creating statistics and reports, you can identify trends, pinpoint bottlenecks, and increase your team’s efficiency. You can find more information here on Statistics Management in OTOBO.

Frequently asked questions

What are the primary ticket states in OTOBO and what do they signify?

OTOBO utilizes a set of predefined ticket states to clearly indicate the processing stage of a ticket, ensuring agents are always aware of which tickets require their attention. These states are fundamental for efficient workflow management and include:

  • new: A ticket that has been opened without any agent contact yet.
  • open: The ticket is currently in progress, with active communication between customers and the assigned agent.
  • pending reminder: The ticket is awaiting further action after a set waiting period, indicating it needs to be revisited.
  • pending auto close (+/-): These tickets are configured to be automatically closed as either successful or unsuccessful once a specified waiting time has elapsed, streamlining resolution for certain types of issues.
  • closed successful: The issue described in the ticket has been fully resolved to the customer's satisfaction.
  • closed unsuccessful: The ticket was closed without a solution being found, perhaps due to irrelevance or inability to resolve.
  • merged: The content of this ticket has been integrated into another existing ticket, often to consolidate related issues.
  • removed: The ticket has been taken out of the system, typically indicating it's no longer relevant or was created in error.
    These states provide a clear overview, facilitating task prioritization and workload balancing within the helpdesk.

Sources:

How are ticket states managed and configured within OTOBO?

Ticket states in OTOBO are centrally managed within the "States" section, which is located under the "Ticket Settings" module in the administration interface. This dedicated area allows administrators to add new states, modify existing ones, and configure their properties to align with the helpdesk's specific workflows. A fresh OTOBO installation comes with a default set of states designed for efficient ticket processing, but these can be customized. To add a new state, you simply select "Add state" from the menu, fill in the necessary details such as the name, state type, and validity, and then save it. It's important to note that states cannot be permanently deleted from OTOBO; instead, they can be deactivated by setting their "Validity" to invalid or temporarily invalid. This approach ensures data integrity and historical consistency, as tickets might still be associated with older states. Editing existing states is straightforward: select the state, make your adjustments, and save. If a state's name is changed, OTOBO performs a validation check to warn of potential conflicts with other system configurations, prompting careful consideration of the impact.

Sources:

What options does OTOBO provide when renaming an existing ticket state?

When an administrator decides to change the name of an existing ticket state in OTOBO, the system presents three distinct options to manage the potential impact on the overall system configuration. These options are crucial for maintaining consistency and preventing errors:

  • Save and update automatically: This is the most convenient option. It applies the name change to the state and automatically updates all other affected settings and references throughout the OTOBO system. This helps ensure that all connections and configurations remain consistent, simplifying system maintenance.
  • Do not save, update manually: Choosing this option means the state's name will be changed, but OTOBO will not automatically update any associated settings. The administrator is then responsible for manually reviewing and updating all active connections and references (such as those in dashboards, action control lists, or processes) to reflect the new state name. This option requires significant caution and thorough understanding of the system's configuration.
  • Cancel: This option aborts the renaming process entirely, making no changes to the state's name or any system settings. It is typically used when the administrator is unsure about the potential consequences of a name change and needs more time to assess the impact.
    It is extremely important to exercise caution when renaming objects in OTOBO, as not all links and dependencies can be automatically verified by the system. Maintaining thorough documentation of your OTOBO configuration is highly recommended to mitigate risks associated with such changes.

Sources:

How can ticket states be utilized for performance evaluation and reporting in OTOBO?

Ticket states in OTOBO are invaluable for evaluating the performance of a service desk and generating critical insights into its operations. By actively monitoring and analyzing ticket statuses, organizations can gain a clear understanding of their team's workload, identify potential bottlenecks, and measure key performance indicators (KPIs). OTOBO facilitates this through various features:

  • Ticket Search: Administrators and agents can use advanced ticket search functionalities to filter and find tickets based on their current state, allowing for targeted analysis.
  • Dashboards: Configurable dashboards provide a visual overview of ticket distribution across different states, offering real-time insights into the helpdesk's status and agent activity.
  • Statistics: OTOBO's comprehensive statistics module allows for the creation of detailed reports that evaluate ticket statuses over time. These reports can reveal trends in ticket resolution, identify common states that tickets get stuck in, and help assess the efficiency of workflows. This enables managers to make data-driven decisions to optimize processes, balance workload, and improve overall service desk responsiveness.
  • Queue and Service Overviews: These specialized views facilitate personalized sorting and provide clear, concise summaries of tickets, often categorized by their state, to help agents prioritize their tasks effectively.
    Effective status evaluation is crucial for continuous improvement and ensuring that the service desk operates at peak efficiency.

Sources:

What are the key settings to consider when configuring a new or existing ticket state in OTOBO?

When configuring or editing a ticket state within OTOBO's "States" section of the Ticket Settings module, several key fields must be considered to define its behavior and appearance accurately. These settings ensure that each state functions as intended within the helpdesk workflow:

  • Name: This field requires a unique name for the state. This name is what agents and customers will see in various overviews and dropdowns, so it should be clear and descriptive (e.g., new, open, closed successful).
  • State type: This crucial setting specifies the fundamental category or type of the state. Examples include closed, new, open, or pending. The state type dictates how OTOBO internally processes and categorizes tickets in that state, influencing system behavior, such as whether a ticket is considered active or resolved.
  • Validity: This determines the active status of the state. Options typically include valid (the state is active and usable), invalid (the state is deactivated and cannot be used for new tickets, though existing tickets might retain it), or temporarily invalid (similar to invalid, but implies a potential future reactivation). Deactivating states is the method used instead of deletion to maintain data integrity.
  • Comment: This field provides an optional space for additional explanations or internal notes regarding the purpose, specific use cases, or any particular considerations for the state. This is highly useful for documentation and for informing other administrators or agents about the state's role.
    Proper configuration of these fields is essential for creating a flexible and robust ticket management system that aligns with your organization's support processes.

Sources:

Are there specific system configuration options in OTOBO that influence the behavior of pending tickets?

Yes, OTOBO provides specific system configuration options that significantly influence the behavior and processing of pending tickets, ensuring that reminder systems and automated workflows function effectively. These options are vital for managing tickets that require a waiting period before further action:

  • Daemon::SchedulerCronTaskManager::Task###TicketPendingCheck: This critical configuration option controls the frequency at which OTOBO's internal daemon checks the status of all pending tickets. It dictates how often the system scans for pending deadlines that have expired. A well-tuned frequency is crucial for the efficiency of the reminder system, ensuring that agents are prompted to revisit tickets promptly and that automated processes for pending tickets are triggered without undue delay.
  • Ticket::StateAfterPending: This setting determines the exact state a ticket automatically transitions to once its pending deadline has expired. For instance, a ticket might move from pending reminder to open if a customer replies, or to closed successful if an auto-close condition is met after a specific waiting period. This configuration is essential for defining seamless workflows and ensuring that tickets continue through their lifecycle without manual intervention after a waiting period, thereby enhancing the responsiveness and automation of your service desk.
    Adjusting these options allows administrators to fine-tune how OTOBO handles tickets that are in a waiting state, optimizing the system's ability to manage follow-ups and automated closures.

Sources: