---
title: "Before You Buy Another Tool: Run This Systems Diagnostic First"
description: Before investing in new tools, assess your existing systems and processes to identify and resolve underlying issues for better efficiency and clarity.
---

[Skip to content](https://www.kerriequeen.com/patterns/before-you-buy-another-tool-run-this-systems-diagnostic-first#main-content)

- ALL
- SYSTEMS
- PROCESS
- AUTOMATION + AI
- OPERATIONS
- GROWTH

[All posts](https://www.kerriequeen.com/patterns/all)

 September 25, 2026

# Before You Buy Another Tool: Run This Systems Diagnostic First

![Picture of Kerrie Queen](https://app.hubspot.com/settings/avatar/09cfd2178550ec1983a95f27fd2b1bdf) By   Kerrie Queen  ·   4 minute read

A new tool can feel like progress. But too often, that hoped-for progress turns into wasted time, wasted money, and a team pulled away from meaningful work just to implement something new.

Why? Because the tool is not always the problem. Sometimes it simply exposes the problem that was already there.

Before you add new technology or automation, start with these six areas. Can you answer the questions under each one? If not, do not start with technology. Start with the system.

 

 1

### Start with the system, not the technology

 2

### Clear ownership is essential

 

 3

### Most breakdowns happen at the handoff

 4

### Good automation depends on good data

 

 5

### Most breakdowns happen at the handoff

 6

### Workarounds reveal what the system is missing

 

### Use these six questions to diagnose the system before you add new technology.

![Question #1](https://www.kerriequeen.com/hs-fs/hubfs/1.png?width=2000&height=1125&name=1.png)

## Who owns this?

Who is fully responsible for its success?

  Who owns the process from beginning to end?  

  Who is responsible for moving each stage forward?  

  Who decides when something is ready for the next step?  

  Who fixes the process when it stops working?  

  Who owns the technology supporting it?  

That person owns the outcome.   
They make sure the right experts and roles are doing their part, and they are accountable when the process succeeds or fails. If several people believe someone else owns the work, a new system will not solve the problem. It will just give the confusion a new place to live. This becomes especially important when automation is involved. 

Autotmation needs a defined point of responsbiliity. If the system identifies an exception, routes a lead, or flags bad data, someone still needs to own what happens next. 

![Question #2](https://www.kerriequeen.com/hs-fs/hubfs/2.png?width=2000&height=1125&name=2.png)

## Do your definitions actually mean the same thing?

A system depends on shared definitions.

Consider a sales team using terms like: **Lead. Qualified. Warm. Opportunity. Active. Closed.** Those labels may appear perfectly clear until you ask five people what they mean.

👱‍♀️ Libby says a lead is warm because they opened an email  
👨‍🦳 Jason labels warm after a conversation.  
👩‍🦰  Ashley says anyone she personally believes is interested is labeled warm

Now imagine asking your CRM to automate what happens when a lead becomes warm.   
The technology cannot resolve a definition the organization has never resolved itself.

A  " priority customer "   

A " completed project "

A " ready for review " task

An " active client "

A " marketing qualified lead "

An " urgent request "

Before automating around a status, category, lifecycle stage, or field, ask:  
**Could two reasonable people look at the same situation and choose different answers?**

If the answer is yes, define the term before you automate it.

 

![Question #3](https://www.kerriequeen.com/hs-fs/hubfs/3.png?width=2000&height=1125&name=3.png)

### Are the handoffs clear?

Most operational problems do not happen while one person is doing the work.  
They happen **between people**.

| Marketing hands something to sales  → |
| --- |
| Sales hands something to operations  → |
| A coordinator hands something to leadership  →   |
| A prospect becomes a customer →   |
| A strategist finishes the plan and implementation begins →   |
| A request gets approved and someone else needs to execute it    |

Look closely at those transition points. For every important handoff, you should be able to answer:

Who sends it?     Who receives it?     What information must be present?       
What event triggers the handoff?     How does the next person know they now own it?       
What happens if nothing happens?

If the answer is "*we usually send them a message*," the problem may not be your software.

The problem may be that the system is relying on humans to remember that another human needs to do something. That is exactly where structured workflows and automation become valuable, but only after the handoff itself has been defined.

![Question #4](https://www.kerriequeen.com/hs-fs/hubfs/4.png?width=2000&height=1125&name=4.png)

### Can your data support the decision you want the system to make?

Every automation is ultimately a decision.   
*If this happens, do that.*

If this  person meets these conditions, then route them here.  
If this record reaches this stage, then send this communication.  
If this account matches this profile, then prioritize it.

If the data required to make that decision is missing, inconsistent, outdated, or stored in a notes field, the automation will fail even if the technology works perfectly.

Before building anything, identify the data the process depends on.

Ask:

1. Is the information being captured?
2. Is it stored in a structured field?
3. Is the field consistently completed?
4. Does everyone use it the same way?
5. Is the data current enough to trust?
6. Does the information live on the right record?
7. Can the system actually access it when the decision needs to happen?
8. This is why data cleanup often becomes part of systems work.

It is not glamorous, but neither is building an elegant workflow on top of unreliable information.

Automation does not fix bad data.  It accelerates whatever your data already tells it to do.

![Question #5](https://www.kerriequeen.com/hs-fs/hubfs/Blog%20Question%20Cards%20%20(2240%20x%201260).png?width=2000&height=1125&name=Blog%20Question%20Cards%20%20(2240%20x%201260).png)

### Where are people working around the system?

This is one of the most useful diagnostic questions you can ask:  
**What are people doing outside the system because the system does not work for them?**

Look for:

📊  Spreadsheets someone maintains on the side.  
📝  Notes copied into personal documents.  
💬  Slack messages used instead of updating records.  
✅  Manual reminder lists.  
📧  Information stored in email threads.  
👎  Fields nobody uses.  
👀  Processes everyone technically follows, except in practice.

These workarounds are not always signs that employees are resisting technology. Often they are evidence.

They tell you where the official system does not match the way the work actually gets done. Do not immediately eliminate the workaround → → → Study it.

Why does the spreadsheet exist?  
Why does someone keep a personal tracker?  
Why is the team messaging each other instead of using the workflow?  
Why does nobody update that property?

The workaround may reveal a missing field, an unnecessary step, a bad interface, an unclear process, or a legitimate need the current system never accounted for.

Your unofficial systems are often the clearest map of where your official system is failing.

![Question #6](https://www.kerriequeen.com/hs-fs/hubfs/Blog%20Question%20Cards%20%20(2240%20x%201260)%20(1).png?width=2000&height=1125&name=Blog%20Question%20Cards%20%20(2240%20x%201260)%20(1).png)

### Is the tool actually the constraint?

Finally, ask the question organizations often skip:  
**What specifically can we not do because of the technology?**

Be precise.

"We hate the CRM" is *not a constraint.*  
"It requires six manual updates to move a deal from signed contract to onboarding" is.

"Our project management system is terrible" *is not a constraint.*  
"There is no reliable way for account managers to see which client deliverables are overdue" is.

"We need AI" is *not a constraint.*  
"Our team spends eight hours every week manually categorizing requests that follow the same predictable rules" might be.

Once you name the constraint, you can evaluate whether technology is actually the right intervention.

Sometimes the answer is a configuration change.  
Sometimes it is a better workflow.  
Sometimes you need cleaner data.  
Sometimes you need to remove three steps instead of automating them.

And sometimes, yes, you genuinely need a different tool.  
The difference is that now you know **why**.

 

## Now, what should technology do?

Once the underlying process is clear, technology becomes much easier to evaluate.

Determine what should be standardized:

- What should be automated.
- What should trigger a notification.
- What information should be required.
- What should move automatically.
- What needs human judgment.
- What should disappear from the process entirely.

That is when technology starts creating leverage instead of adding another layer of complexity.

The goal is not to build the most sophisticated stack.

It is to create a system where the work is clear, the information is useful, the next action is obvious, and technology removes friction instead of introducing more of it.

Before you rebuild the tool, understand the work. The technology comes second.

Share: [linkedin-in icon](http://www.linkedin.com/shareArticle?mini=true&url=https://www.kerriequeen.com/patterns/before-you-buy-another-tool-run-this-systems-diagnostic-first) [envelope icon](mailto:?body=https://www.kerriequeen.com/patterns/before-you-buy-another-tool-run-this-systems-diagnostic-first)

 

Kerrie Queen

Contact

Copyright © 2026

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Kerrie Queen",
    "url" : "https://www.kerriequeen.com/patterns/author/kerrie-queen"
  },
  "dateModified" : "2026-09-25T19:29:58.458Z",
  "datePublished" : "2026-09-25T19:11:06.000Z",
  "headline" : "Before You Buy Another Tool: Run This Systems Diagnostic First",
  "mainEntityOfPage" : {
    "@id" : "https://www.kerriequeen.com/patterns/before-you-buy-another-tool-run-this-systems-diagnostic-first",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://www.kerriequeen.com/hubfs/4%20Dot%20Circle%20Logo%2c%20Transparent%20Background.png"
    }
  }
}
```

```json
{
  "@context" : "http://schema.org",
  "@type" : "Article",
  "author" : {
    "@type" : "Person",
    "name" : [ "Kerrie Queen" ]
  },
  "datePublished" : "2026-09-25T19:11:06+0000",
  "description" : "Before investing in new tools, assess your existing systems and processes to identify and resolve underlying issues for better efficiency and clarity.",
  "headline" : "Before You Buy Another Tool: Run This Systems Diagnostic First",
  "image" : "",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://246717309.fs1.hubspotusercontent-na2.net/hubfs/246717309/4%20Dot%20Circle%20Logo%2c%20Transparent%20Background.png"
    },
    "name" : ""
  },
  "url" : "https://www.kerriequeen.com/patterns/before-you-buy-another-tool-run-this-systems-diagnostic-first"
}
```