Why Service Is Where IT Credibility Begins

When most people think about IT, they don't think about architecture diagrams, compliance frameworks, or vendor negotiations. They think about getting help. They think about the person or team they can turn to when something isn't working, when they're blocked, or when they don't know where else to go. That expectation is the foundation of trust between IT and the rest of the organization, and it's the first thing I focus on whenever I start working with an organization.

Establishing a Service Management System

The first obstacle you will face is implementing, or re-implementing, a service management system to handle requests and incidents across the organization. In many environments, there is no true system, only a collection of habits such as emails, Slack messages, walk-ups, and side conversations. Establishing a singular, intentionally designed service management system is often the first real change I make.

If your organization is large enough to have someone with an IT job title, you are already at the right stage to start applying these practices. In fact, earlier is often better. Expectations form quickly, and it is much easier to establish healthy service habits before informal patterns harden into culture. Organizations that do not yet have dedicated IT staff and operate in a shared or part-time model should still aim for these principles, but doing so will be more difficult when IT responsibilities are spread across many roles.

When I refer to a service management system, I mean the single system of record where all service requests, incidents, communication, and outcomes are tracked. In my work, that system is most commonly Atlassian Jira Service Management, though the specific platform matters far less than the discipline around it. Many of the practices here draw from ITIL, but you don't need formal certification to apply them—just intentionality. What matters is not that a system exists, but that it is clearly the place where service work lives.

Leadership Sets the Standard for Service Discipline

Once the system exists, the first group that needs to change its behavior is the IT team, starting with leadership. Expectations must be the same for everyone, whether it is an entry-level service desk technician or you as the IT leader. The fastest way to undermine a service management system is for leaders to bypass it themselves. If your team sees you handling work in Slack or private messages, they will assume that behavior is acceptable and follow suit.

In practice, side-channel requests often show up as a quick direct message asking for help, which is exactly the moment where consistency matters.

Worker: Spiva, can you help me get access to the new screen recording app the design team is using? Me: Howdy. My team would love to get you going with the new screen recording app. Can you kick off the process at our service portal?

Most side-channel requests are not malicious, even in highly mature organizations with strong service discipline. We are human, and people reach for what feels familiar in the moment. Redirecting these requests is not about correcting behavior, but about reinforcing the system.

Redirecting requests into the service management system prioritizes long-term outcomes over short-term convenience. It ensures the right people see the work, that it is handled consistently, and that the organization can learn from it over time. This is not about being unhelpful. It is about being predictably helpful at scale. When leaders model this behavior, they are not pushing work away; they are protecting the health of the service, the team, and the organization as a whole.

Enabling Workers to Provide Better Information

Once internal behavior is aligned, focus can shift outward to the workers you support. The goal is to enable them to give you the information you need to serve them effectively, without forcing them to understand how IT works internally. One practical example of this is encouraging workers to submit requests through a service portal rather than email or team chat tools like Slack or Microsoft Teams. Those chat tools are excellent for collaboration and quick conversations, but they are poorly suited for getting the right information up front and tracking long-lived work.

A service portal is different by design. It gives you structured data about who is asking for help, what they need, and how urgent the issue may be. It can also surface context automatically, such as assigned devices, applications, or recent changes, without requiring workers to think about any of that explicitly. When a chatbot is embedded directly into the service portal, it functions as an extension of that intake process. Unlike general-purpose chat tools, a portal-based chatbot can guide workers through requests, ask clarifying questions, and interact with automation or knowledge in a way that feeds directly into the service management system.

This approach assumes the service portal itself is usable. If the portal is slow, confusing, or overly complex, workers will avoid it and fall back to familiar chat channels. Making the portal simple, fast, and designed around common needs is part of the work. When done well, the portal becomes the easiest and most reliable path, not an obstacle.

Just as importantly, workers need to be taught how and when to use the portal. This typically starts during onboarding, where expectations around requesting service are set early and reinforced as part of how work gets done. Clear links, simple language, and consistent reinforcement from managers all help make the service portal the obvious first stop. Over time, familiarity replaces friction, and workers stop thinking about how to ask for help and focus instead on what they need.

One practical technique I have used in many organizations: make submitting a service request part of every new worker's first day. As the final step of device and account setup, each new worker submits a simple ticket themselves. This creates immediate muscle memory, removes hesitation about using the system, and establishes the service portal as the normal way to ask for help from day one.

Using Automation and AI to Improve the Service Experience

Modern service portals can go further. They can offer guided request flows, surface relevant knowledge articles, or allow workers to interact with a chatbot backed by a large language model trained on your internal documentation and service history. In many cases, this means workers get an answer immediately, or at least arrive at the request with clearer intent and better detail. This reduces repetitive work and improves consistency. For workers, it feels faster, more responsive, and more modern. Over time, this reinforces the portal as the default entry point whenever help is needed.

As portals become more capable, they also enable something equally important: ticket deflection. When workers can find answers through knowledge articles, guided workflows, automation, or AI-assisted interactions, many requests are resolved without ever requiring a human IT agent. For workers, the outcome is faster and less disruptive. From the IT team's perspective, this reduces repetitive work and preserves capacity for higher-impact issues. Effective deflection is not about avoiding service; it is about delivering the right outcome at the earliest possible moment, often before a ticket ever needs to be created. When done well, deflection shows up in the metrics as lower ticket volume without a corresponding drop in response times, resolution times, or worker satisfaction.

Service Work, Projects, and Sensitive Requests

Not all IT work belongs in the service management system forever. As a general rule, service requests and incidents are items that can be completed within days, not weeks. Very rarely should a service desk ticket remain open for more than a week. When work grows beyond that scope, it is usually a signal that it should be transitioned into a different form of work management, such as a project or initiative tracked elsewhere.

The boundary between service work and project work is not always clean, but time is often the most practical signal. Separating service work from project work helps keep the service system focused and responsive, while allowing larger efforts to be planned, staffed, and communicated appropriately. Without this separation, service queues become cluttered with long-running work that obscures visibility and undermines expectations.

There are also rare cases where requests are sensitive or confidential, particularly those involving executives or organizational changes. In these situations, it can be appropriate to handle the work initially through a private channel, such as a small Slack conversation, while the topic remains sensitive. In most cases, once the action has been taken or the information is no longer confidential, the work can and should be formalized in the service management system for tracking and accountability. These cases should remain true exceptions, handled deliberately by leadership, and not become an alternate path for routine requests.

Defining Priority, Response Time, and Resolution Time

Before service level objectives can be meaningful, priority must be clearly defined. Priority is not about who is asking or how loudly they are asking. It is a shared agreement about business impact and urgency. Response time and resolution time flow from that agreement and give structure to how service is delivered.

At a high level, priorities describe how much the organization is impacted and how quickly work needs attention:

• Highest: Core systems are unavailable or severely degraded. Work cannot continue. This is the "wake someone up at 2 AM" tier.
• High: Significant degradation or partial outages. Work can continue in a limited fashion, but immediate attention is required.
• Medium: Standard service requests and non-urgent issues.
• Low: Routine or low-impact work with little urgency.
• Lowest: Informational requests or nice-to-have changes.

Response time is the amount of time between a request being submitted and a human acknowledging it. This means a person, not an auto-reply. It doesn't mean fixed—just seen, triaged, and acknowledged. Resolution time is the amount of time between submission and the issue being fully addressed or the request completed. These measures serve different purposes. Response time builds trust and reduces uncertainty. Resolution time reflects the actual effort and complexity involved in delivering the outcome.

In practice, priority disagreements will arise. Early on, it is rarely worth spending much time debating them in the moment. When there is uncertainty, it is usually better to round up to a higher priority and move forward. As service maturity increases, introducing clearer examples and tighter definitions for each priority can be useful, but simplicity and momentum matter more than precision at the start.

Setting Reasonable Service Level Objectives

Service level objectives make expectations explicit and shared. They define how quickly IT responds and resolves work, and the calendar those expectations apply to. Before defining targets, it is important to understand when service is expected to be available, when on-call coverage is required, and to keep the model simple and clearly communicated.

Service Level Objectives by Priority

All response and resolution times are measured within the stated calendar and begin once a request enters the service management system.

Calendars and time-based expectations should change rarely. They represent an agreement between you, your stakeholders, and the organization. The part that should remain flexible is the performance target, or how often IT is expected to meet these objectives. Early on, it is reasonable to target something conservative, such as 80 percent. As data accumulates and maturity improves, that target can be raised.

Measuring What Matters

Once service level objectives are defined, measurement becomes meaningful. Metrics are no longer abstract numbers pulled from a system. They become a way to understand whether expectations are realistic, whether the service model is working, and where friction remains. I focus on a small set of signals that map directly back to the objectives themselves: request volume, completion rate, response time compliance, resolution time compliance, and average response and resolution times.

Measurement is also where leadership responsibility becomes explicit. No one else is going to define what success looks like for IT. As an IT leader, you have to do the work to understand how your organization operates, where service friction exists, and what trade-offs are reasonable. That understanding is built through data, conversations, and engagement with stakeholders across the business. Only then can you use metrics to communicate clearly with your management chain and help the organization make informed decisions.

The most important part of measurement is not a dashboard, but the conversation it enables. Reviewing these metrics with your IT team builds shared understanding of workload and tradeoffs. I will often review these metrics weekly with my team and publish them monthly to management and peer groups.

That communication does not need to be complex to be effective. In some organizations, I have published a simple monthly internal blog post summarizing service metrics and notable work. In others, I have sent a short email to leadership with the same information. Just because it feels like no one is listening does not mean the information is not landing. Consistent communication builds trust over time.

Missing a service level objective is not a failure by itself. What matters is understanding why it happened and being able to explain it clearly to both your team and your leadership. Service targets are the result of trade-offs between staffing, budget, available time, and competing priorities. In some cases, an organization may knowingly accept a short-term degradation in service to focus on another critical initiative. While this can be the right decision briefly, sustained trade-offs that consistently harm service delivery tend to have compounding negative effects.

Strong, ongoing communication is essential here. Leaders and teams need shared visibility into which trade-offs are being made and why. By focusing on service first, I am making a clear statement: service is the most important function an IT organization delivers. That does not mean it must be perfect every moment of every day, but it does mean that any decision to compromise service should be deliberate, understood, and revisited frequently.

This Is Where the Playbook Begins

Service is the most visible function of IT and often the most emotionally charged. It is where trust is built or lost, usually long before architecture or strategy are ever noticed. When intake is clear, behavior is consistent, expectations are explicit, and performance is measured honestly, service delivery becomes predictable.

That predictability is what allows IT to be seen not just as a service function, but as a reliable partner to the organization. This is why I start here. Before roadmaps, before platforms, before long-term transformation efforts, I focus on how people ask for help and what happens when they do. Getting this right creates credibility, alignment, and momentum that carries forward into every other part of the IT organization.