Fixify Glossary

Application Management is a system that automatically discovers, maps, and manages applications across an organization — including ownership, approval workflows, and access provisioning.

‍

Application Management operates through three core functions: discovery, definition, and automation. The system automatically discovers applications by analyzing support tickets for application references and reviewing identity provider integrations like Okta, Google Workspace, and Entra ID. This includes sanctioned business applications, shadow IT, and custom internal tools — if a user requests it in a ticket, it gets added to the inventory. Once applications are discovered, IT teams define owners, approvers, access policies, and provisioning steps in the Application Matrix. When an access request arrives, the system maps it to the appropriate approval workflow and provisioning steps defined in the Application Matrix, enabling automated resolution based on predefined rules. Discovery runs continuously, ensuring the system reflects current application usage and organizational structure without requiring manual inventory updates.

‍

Bottom line: Application Management turns app chaos into structured automation — so IT knows what exists, who owns it, and how to provision access without hunting for answers every time.

The Application Matrix (App Matrix) is a continuously updated inventory of all applications in a customer's environment, including ownership, approval workflows, and provisioning details.

‍

The Application Matrix serves as the central repository for application data within Application Management. It lists every known application, including business and technical owners, access policies, related ticket history, SSO status, and associated identity provider groups. The App Matrix pulls approver information directly from directory services like Active Directory or Entra ID and verifies that approvers are active employees before routing requests. IT teams use the App Matrix to define access policies for each application — from auto-approval for company-wide tools to manager approval or business owner sign-off for specialized systems. The matrix updates continuously as the environment changes: new applications are added when they appear in tickets or identity integrations, ownership updates when personnel changes occur, and approval workflows adjust when approvers leave the organization. This ensures that access request automation always operates on current data.

‍

Bottom line: The Application Matrix is your living map of who owns what and how access gets granted—eliminating the guesswork from every app request.

‍

Approval Procedure Guidelines define how analysts initiate, track, and respond to approval requests within a customer's IT environment.

‍

Approval Procedure Guidelines clarify the process for managing approvals without blocking ticket progress. They specify how to initiate an approval request, expected wait times, appropriate follow-up methods, and next steps if an approval is denied. These guidelines ensure analysts can navigate approval workflows consistently across different customer environments.

‍

Bottom line: Fixify turns approval bottlenecks into documented workflows — so requests can be automated even when they need sign-off.

The Conversational UI is the primary interface where IT analysts supervise automations and – when necessary – communicate live with end users, approve and execute tasks.

‍

The Conversational UI is the central workspace for supervising automated workflows in Fixify. Analysts use this interface to see how workflows are being automated in real time. If needed they can also chat with end users, run skills that gather necessary context or take action on requests, and apply playbooks to guide resolution. All work is logged within this space for visibility and traceability so there’s a single source of truth for each automated task. Summaries are also written directly to the ITSM.

‍

Bottom line: The Conversational UI is where analysts supervise automations, engage with end users, and drive ticket resolution to completion — with every action logged and synced to the ITSM.

Decision Support features help ensure Fixify AI agents (and human IT experts when necessary)  make faster, more informed decisions when navigating complex or ambiguous support scenarios.

‍

Decision support refers to any feature designed to assist AI agents or IT analysts in handling requests that could follow multiple paths. These features provide contextual guidance to improve decision speed and consistency. Examples include triage decision support, which surfaces customer-specific instructions and suggests likely triage reasons, and contextual summaries that highlight relevant user history (such as frequent account lockouts) to inform the recommended approach. 

‍

Bottom line: Fixify gives AI agents and IT analysts the context they need to make smart calls fast — without sacrificing quality or consistency.

Escalation Procedure Guidelines define how Fixify AI agents escalate requests within a customer's IT environment.

‍

Escalation Procedure Guidelines outline the approved methods when AI agents (or the IT experts supervising them) need help on complex requests. They specify which communication channels to use, how to document the escalation, and how to track progress through resolution. These guidelines ensure AI agents can escalate requests clearly and consistently without needing to determine the correct process case-by-case.

‍

Bottom line: Escalation Procedure Guidelines eliminate guesswork so our AI agents (and IT experts supervising them) know exactly how to get help when they need it.

Guidelines are company-level operational procedures that help Fixify AI agents navigate customer-specific environments consistently across use cases.

‍

Guidelines are structured, step-by-step instructions designed for each customer at the organizational level. Unlike playbooks, which address specific use cases, guidelines apply broadly across multiple scenarios. They often include conditional logic (if X occurs, then do Y) to help AI agents (and the IT experts that supervise them) make appropriate decisions based on context. Guidelines serve two primary functions: they orient automations to each customer's unique environment and provide a repeatable framework for progressing requests from one state to the next. This structure enables AI agents to deliver consistent, high-quality support tailored to each customer without starting from scratch on every request.

‍

Bottom line: Guidelines give AI agents and analysts a consistent, customer-specific framework for navigating requests — so every interaction is informed, repeatable, and tailored to the environment from day one.

The Knowledge Hub is a structured repository of customer-specific documentation, including playbooks, guidelines, and procedural instructions.

‍

The Knowledge Hub organizes company-specific guidance into a searchable, accessible format. Content types include playbooks, triage guidelines, request handling procedures, escalation guidelines, and approval guidelines. The repository is designed to make critical information about customer environments and processes easy to locate and apply. Customer and customer success team members can edit content directly within the product. The Knowledge Hub ensures that tribal knowledge becomes documented, actionable guidance, enabling our AI agents and the humans that supervise them to operate with confidence and consistency regardless of shift timing or customer assignment.

‍

Bottom line: The Knowledge Hub makes sure the right answer is always within reach — turning institutional memory into institutional reliability.

Resolution Time is the total time from when a support request is created until it reaches a completed state.

‍

Resolution Time, also called service time, measures the full lifecycle of a support ticket — from creation through final closure. This metric captures all time spent in the open ticket lifecycle, regardless of status changes along the way. Resolution time varies significantly based on request complexity, customer-specific processes, available integrations, and whether the request requires external approvals or end user input. It serves as a core metric for evaluating how efficiently support outcomes are delivered.

‍

Bottom line: Resolution Time tells you how long it takes to actually fix the problem — not just how fast someone responded.

The Service Catalog is a structured taxonomy of IT help desk services, organized into categories and use cases.

‍

The Fixify Service Catalog defines the scope of typical IT help desk coverage, from password resets to software provisioning. Fixify created the categories and use cases within the Service Catalog so they don’t follow an industry standard framework. The catalog serves multiple purposes: it defines the scope of automations we create, and standardizes service expectations. It’s also used to shape metrics about the type and amount of work Fixify is automating and how end users feel about it

‍

Bottom line: The Fixify Service Catalog is the definitive reference for the categories and use cases of IT help desk support that Fixify is automating.

A Service Level Agreement (SLA) defines contractual performance thresholds for minimum response times based on support request priority level.

‍

SLAs establish the formal performance obligations between the service provider and customer. Current SLA response time targets during business hours are: Priority 1 (Critical) - 1 hour for service unavailability affecting all users; Priority 2 (High) - 1 hour for issues blocking user work, such as login failures; Priority 3 (Medium) - 4 hours for issues impacting productivity, such as application access requests; Priority 4 (Low) - 8 hours for non-critical work items like distribution list additions. SLAs represent contractual minimums and are intentionally set higher than internal service level objectives to allow for exceeding customer expectations.

‍

Bottom line: SLAs are the floor, not the ceiling — Fixify aims to exceed them consistently so they rarely come up in conversation.

Service Level Objectives (SLOs) are internal performance targets that define desired service quality beyond contractual minimums.

‍

SLOs are internally defined metrics that teams aim to meet for every support interaction. Unlike SLAs, which are contractual obligations, SLOs represent aspirational performance standards. They may be discussed with customers but are not part of contract terms. SLOs are typically more stringent than SLAs and serve as the primary reference point for internal performance discussions and operational planning.

‍

Bottom line: SLOs are what Fixify actually holds itself to — higher standards than what's written in the contract.

Skill Error Codes are standardized codes that indicate why a skill execution failed.

‍

Skill error codes identify the specific reason an automated action could not complete successfully. The codes include: permission denied (the API returned an error indicating insufficient permissions to perform the action), invalid config (the integration is missing required configuration settings), invalid auth (the API rejected authentication, potentially due to an incorrect or expired API key), and invalid input (the action failed because input parameters were missing or incorrectly formatted). These codes help analysts and administrators quickly diagnose and resolve issues with automated skill execution.

‍

Bottom line: Skill Error Codes turn vague failures into actionable fixes — so automation gets back on track fast.

Skills are automated tasks executed through integrations with IT systems, such as password resets or account unlocks.

‍

Skills are technical actions that can be performed programmatically via integrations with IT tools and platforms. They automate routine support tasks, standardize execution across different systems and customers, and abstract technical complexity so analysts can focus on outcomes rather than implementation details. Skills reduce manual effort, minimize errors, and improve response speed. They are foundational to delivering consistent, scalable support experiences for both analysts and end users.

‍

Bottom line: Skills turn repetitive IT work into one-click actions—so analysts spend time solving problems, not clicking through consoles.

States are defined stages that track a support request's progress from creation through completion.

‍

Triage — Initial classification point for all incoming requests; determines whether the work should be automated by Fixify or handled by the customer’s IT team. Requests move to Open if accepted or may jump directly to terminal states (Resolved, Canceled, Duplicate) if no action is required. Requests cannot return to Triage once they have left this state.

‍

Open — The request has been triaged and accepted but no active work has begun. Requests move to In Progress when work starts. Requests cannot return to Triage or move directly to terminal states from Open.

‍

In Progress — Active work is underway. Requests may move to Waiting for Customer or Waiting for Approval if blocked, or to Resolved, Canceled, or Duplicate once work is complete. Requests can return to In Progress from waiting states.

‍

Waiting for Customer — Work is paused pending information or action from the end user. Requests resume in In Progress once the customer responds.

‍

Waiting for Approval — The request is blocked pending approval, often from the customer's organization. Requests resume in In Progress once approval is received.

‍

Resolved — The request has been completed and an appropriate outcome delivered. Typically follows In Progress but may follow Triage if no work was required.

‍

Canceled — The request is no longer relevant (user withdrew request or need no longer exists). Entered from In Progress or Triage.

‍

Duplicate — The request duplicates an existing or completed ticket. Entered from Triage or In Progress.

‍

Closed — Terminal state with currently unclear definition; potentially redundant with Resolved. [Note: Needs product/operations input to determine if this state should be retained or removed.]

‍

Bottom line: States give everyone visibility into where a ticket stands — and what needs to happen next to move it forward.

Time to First Response is the time between when a support request is created and when the first message is sent to the end user.

‍

Time to First Response measures how long an end user waits before receiving initial communication after submitting a request. This metric captures the time from request creation to the first outbound message — whether sent via Slack, Microsoft Teams, email, or a comment in the ticketing system. Any message that clearly indicates work has begun qualifies as a first response and stops the measurement clock.

‍

Bottom line: Fast First Response times signal that help is on the way — reducing user anxiety and setting the tone for resolution.

Triage is the process of evaluating a new support request to determine if it should be automated by Fixify and whether it can be resolved with available resources.

‍

Triage is the initial assessment phase for every incoming support ticket. During triage, Fixify answers two questions specific to each customer: Should this request be automated (does it fall within agreed scope), and can it be automated effectively (are the necessary access, context, and tools available). This decision point is critical because it determines service coverage and sets expectations. The goal is typically to accept approximately 75% of incoming volume. The most common triage error is declining requests that could have been successfully handled, which represents missed opportunities to demonstrate value and deliver service. Whether it can be resolved with available resources.

‍

Bottom line: Triage is where Fixify decides what to take on — and gets it right so customers see consistent, predictable coverage.

Triage Guidelines are structured documentation that helps Fixify AI agents determine which requests to accept and how to handle them after triage.

‍

Triage Guidelines are customer-specific instructions that help our AI agents answer two key questions: Is this request within scope for us to handle, and what actions should be taken once a decision is made? These guidelines reduce the need for human supervision to seek clarification on edge cases and enable fast, consistent triage decisions. They ensure that accepted requests align with customer expectations and that declined requests are handled appropriately.

‍

Bottom line: Triage Guidelines turn ambiguity into clear action — so Fixify AI agents know exactly what's in scope and what to do next.

Triage Reasons are standardized outcomes that indicate why a request was triaged in a specific way.

‍

Triage reasons are the only permitted outcomes when classifying a support request during triage. They include:

‍

NULL — The request never entered triage (applies to manually uploaded tickets, historical tickets that were re-synced, or tickets created at organizations not yet in active service).

‍

ENTERED_TRIAGE — The request entered the triage queue or was routed to the service provider.

‍

ALREADY_STARTED — The request falls within scope, but customer IT had already begun work by the time an analyst reviewed it.

‍

CANT_DO — The request should be within scope, but necessary information or system access is missing (such as required playbook details or system permissions).

‍

OTHER — A catch-all option for edge cases that don't fit other categories; should be used sparingly.

‍

OUT_OF_SCOPE — The request explicitly falls outside the agreed service scope as defined by the customer.

‍

Bottom line: Triage Reasons create a shared language for why tickets go where they go—making patterns visible and decisions auditable.

Wait Times are the amount of time a request spent idle in a given stage before work began or resumed.

‍

Wait times measure how long a request sat without active attention during a specific phase. Examples include wait time for triage (how long the ticket sat before triage began) or wait time before first response (the combined time from when the request entered the triage queue, through triage completion, until the first message was sent to the end user). Wait times exclude periods of active work and focus solely on idle time.

‍

Bottom line: Wait Times show where tickets are sitting — helping identify bottlenecks and improve responsiveness.

Work Time is the amount of time analysts actively spent working on a request during a specific phase.

‍

Work time estimates the duration of active effort within a given stage of the ticket lifecycle. This metric excludes time when the ticket was idle, such as waiting for customer responses or approvals. For example, work time for triage measures how long the AI agent – or IT experts supervising the AI agents – spent actively reviewing and deciding on the request, excluding the time the ticket sat in queue before work began.

‍

Bottom line: Work Time tracks actual effort — separating hands-on work from waiting, so you know where analysts are really spending their time.