Insights

Three Linguistic Red Flags to Spot Improvement Opportunities in Every Conversation

Written by Michelle C | 1 June 2025

There you are, in your Service Improvement team meeting and you get to your third-party escalation processes. You ask the team how things are going with logging tickets to suppliers, and immediately someone responds: "We're mainly quite good at that - most tickets get logged properly."

 

The room nods. It sounds like everything's going well. You could easily move on to the next item.

 

But here's what you might have missed: that single word "mainly" just revealed a critical bottleneck that's probably impacting your customers and burning out your team. And it's not the only linguistic red flag you should be listening for.

 

The Hidden Language Patterns Sabotaging Your Service Desk

Service Desk professionals are brilliant at solving technical problems. We can troubleshoot complex network issues, resolve intricate software conflicts, and manage multiple priorities under pressure. Yet when it comes to the language we use with our teams, customers, and stakeholders, we might be unknowingly revealing exactly where our service improvement opportunities lie.

There are three words that act like linguistic smoke alarms in your service environment. When you hear them, they're telling you something important about your team's mindset, your processes, and your Service Delivery consistency.



Language Red Flag #1: "But"

The word "but" is everywhere in our daily communications:

  • "I hear you, but we should prioritise the server upgrade first."
  • "That might work, but we don't have the resources right now."
  • "No disrespect, but the customer's expectations are unrealistic."
  • "Yes, I know this incident escalated, but the root cause was outside our control."

Here's the problem: Every time someone uses "but," they're essentially telling the other person that everything they've just said doesn't matter. You're negating their input, dismissing their concerns, and setting up a defensive dynamic that makes collaboration nearly impossible.

What "but" reveals: Communication breakdowns, defensive thinking, and an environment where people feel they need to fight to be heard rather than work together to solve problems.



Language Red Flag #2: "Try"

Listen carefully in your next team meeting. How often do you hear:

  • "I'll try to get that ticket resolved by end of day."
  • "We'll try to implement the new process next week."
  • "Let's try to improve our response times."
  • "I'll try to remember to update the documentation."


Here's the problem: "try" gives permission to fail before you even start. It's a linguistic escape hatch that allows people to attempt something without committing to actually achieving it. But the impact goes beyond internal accountability - it also leaves customers uncertain about what will actually be delivered. When your team uses "try," they're not setting clear expectations with customers, who are left wondering whether you're genuinely committed to resolving their issue or just having a tentative go at it.

What "try" reveals: Lack of commitment, unclear accountability, processes that aren't properly defined or supported, and customer uncertainty. This creates customer anxiety and erodes confidence in your service delivery - they can't plan or set expectations with their own stakeholders when your language is wishy-washy.

 

Language Red Flag #3: "Sometimes" and "Mainly"

This one's particularly revealing in service improvement discussions:

  • "Sometimes the monitoring alerts don't come through."
  • "We sometimes follow the change management process."
  • "We're mainly quite good at logging third-party tickets."
  • "Our documentation is mainly up to date."
  • "We mainly stick to our escalation procedures."
  • "Most of the time we get tickets logged properly."

 

Both "sometimes" and "mainly" are the language of inconsistency. Whether you're admitting something only happens occasionally ("sometimes") or claiming it usually happens ("mainly"), you're revealing processes that aren't reliable, standards that aren't consistently applied, and service delivery that varies depending on circumstances.

 

The hidden danger: "Mainly" sounds positive, so it's easy to skip over. But when you dig deeper into that "mainly quite good" response about third-party ticket logging, you discover that all third-party tickets need to be logged via one individual. When they're out of office, nothing gets logged. They've become the bottleneck, impacting customers and sacrificing their work-life balance.

 

What "sometimes" and "mainly" reveal: Process dependencies on individuals rather than systems, single points of failure, and improvement opportunities hiding behind seemingly positive language.

 

Now that you know what to listen for, here's how to address each red flag...


How to Fix it:

The Agreement Frame: Replacing "But" with "And"

Let's start with the easiest fix. Instead of using "but," replace it with "and." It sounds almost too simple to work, but the psychological impact is profound.


Instead of: "The team responded quickly, but the communication to stakeholders was poor."

Use: "The team responded quickly, and the communication to stakeholders needs improvement for next time."

Instead of: "I understand your frustration, but this issue is outside our SLA scope."

Use: "I understand your frustration, and let me explain how we can address this within our current agreement."

Instead of: "Your solution is creative, but it's not practical for our environment."

Use: "Your solution is creative, and let's explore how we might adapt it for our environment."

The "and" version acknowledges what's been said while still introducing your perspective. It creates space for both viewpoints to coexist rather than positioning them as opposing forces.



Eliminating "Try" and Building Commitment

When you hear "try" in your service environment, challenge it immediately:


Instead of: "I'll try to get that ticket resolved by end of day."

Use: "I will get that ticket resolved by end of day" or "I can get that ticket resolved by 2pm tomorrow."

Instead of: "We'll try to implement the new process next week."

Use: "We will implement the new process on Tuesday" or "We need additional resources to implement the new process next week."

Instead of: "Let's try to improve our response times."

Use: "Let's improve our response times by implementing X, Y, and Z" or "Let's identify what's preventing us from improving our response times."

The key is moving from tentative language to either firm commitment or honest assessment of what's needed to achieve the goal.



Addressing "Sometimes" with Process Consistency

When you hear "sometimes" or "mainly," you've identified a process improvement opportunity:

When you hear: "Sometimes the monitoring alerts don't come through."

Dig deeper: "What causes the monitoring alerts to fail, and how do we make them 100% reliable?"

When you hear: "We sometimes follow the change management process."

Dig deeper: "What prevents us from following the change management process every time, and how do we remove those barriers?"

When you hear: "We're mainly quite good at logging third-party tickets."

Dig deeper: "What happens when you're not quite good at it? When does the process break down, and what's the root cause?"

When you hear: "Our documentation is mainly up to date."

Dig deeper: "Which documentation isn't up to date, and what's preventing consistent maintenance?"

When you hear: "Sometimes the customer gets frustrated with our response times."

Dig deeper: "What's different about the times when customers aren't frustrated, and how do we make that the standard?"

 

The key is recognising that both "sometimes" (admitting occasional failure) and "mainly" (claiming usual success) reveal the same underlying issue: inconsistent processes that depend on circumstances, individuals, or luck rather than systematic excellence.

 

This approach turns every instance of inconsistent language into a specific improvement action that addresses the root cause rather than just the symptom.



Practical Implementation in Your Service Environment

During Team Meetings

Start listening for these three words in every interaction. When you hear them, pause the conversation:

  • "I noticed you said 'try' - what do you need to make this a definite commitment?" (much better than my blunt "Try? Are you going to do it or not?" approach)
  • "You mentioned 'sometimes' - help me understand when this works well and when it doesn't."
  • "I heard 'but' - let's rephrase that using 'and' and see how it changes the conversation."


In Customer Conversations

Your language choices directly impact customer confidence:

Instead of: "We'll try to have this resolved soon."

Use: "We will have this resolved by 3pm today" or "We're investigating and will update you within the hour."

With Your Team

Model the language you want to hear:

Instead of: "We sometimes struggle with priority management."

Use: "Our priority management process needs improvement in these specific areas..."

 


The Ripple Effect of Conscious Language

When you start addressing these linguistic patterns, several things happen:

  • Increased Accountability: Removing "try" forces people to either commit properly or identify what's preventing commitment.
  • Improved Processes: Addressing "sometimes" reveals inconsistencies that can be systematically fixed.
  • Better Collaboration: Replacing "but" with "and" creates more collaborative problem-solving conversations. 
  • Enhanced Customer Confidence: Precise, committed language builds trust with customers and stakeholders.

 

Beyond Words: Building a Service Control Centre

The language your team uses is a direct reflection of your service maturity. Teams operating chaotic "Wild West" service desks use tentative, defensive, inconsistent language. Teams running streamlined Service Control Centres use precise, committed, collaborative language.

 

When you address these linguistic patterns, you're not just improving communication - you're identifying and fixing the underlying Service Delivery issues they reveal. Every "but" you replace with "and" makes your team more collaborative. Every "try" you challenge builds accountability. Every "sometimes" you investigate improves consistency.

 

Changing communication patterns takes time and practice. Don't expect perfection immediately. Start small, be patient with yourself and your team, and focus on progress rather than perfection.

 

So, the next time you're in a service review, incident debrief, or customer conversation, listen carefully to the language being used. Those three little words - "but," "try," and "sometimes" - are telling you exactly where your biggest Service Improvement opportunities lie.