Lessons from the field

Most business owners do not need another dashboard.

They already have dashboards. They have alerts. They have reports. They have emails. They have spreadsheets. They have systems that technically contain the information they need.

The problem is not access to information.

The problem is having to check everything manually, connect the dots, decide what matters, and then turn that into action.

That was the problem JB, owner of Uptime Technologies, was dealing with.

Uptime Technologies is an MSP, which means the business is responsible for monitoring client systems, responding to issues, managing tickets, and staying ahead of problems before they become emergencies. Like many MSP owners, JB already had the right tools in place. His team used their RMM platform. They had ticket data. They had information coming through email and spreadsheets. The issue was that the information was spread out.

Every morning, JB had to log into the RMM platform, look through monitoring signals, check what needed attention, understand what tickets had to be created, and decide who should handle what. That kind of work matters, but it is not where an owner should spend the first part of every day.

We provided JB with an AI assistant built around his actual workflow.

An AI assistant is a new way of working. Instead of logging into multiple systems, checking scattered information, and piecing together what matters, the owner has a working layer that helps surface what needs attention and supports decision-making in real time.

This is the kind of assistant we provide. It does not replace the systems a business already uses. It works with them.

Instead of logging into multiple places and reviewing dashboards manually, JB can get a concise view of what needs attention. The assistant reviews monitoring signals, helps surface important issues, connects context from ticket data, and can synthesize information from email and spreadsheets.

That saves him about 45 minutes every morning.

But the larger point is not just the time savings.

The real value is that the business owner starts the day with clarity. He knows what matters. He knows what needs action. He can ask follow-up questions. He can use the assistant to help prepare QBR reports. He can move from checking systems to leading the business.

For MSPs, this matters twice.

First, it helps the MSP owner run their own company better. Second, it creates a new service opportunity for their clients. If an MSP can use assistants to monitor its own operations, summarize risk, prepare reports, and reduce manual review, then the same idea can be applied to the businesses they serve.

Most companies need someone to tell them what is important, what is broken, what is slipping, and what needs to happen next.

That is what JB's assistant started doing.

The lesson is simple: the best first AI project is usually not the biggest one. It is the one that removes a recurring pain from the owner's day.

For JB, that started with his morning review.

For another business owner, it might be sales follow-up, cash flow visibility, open tickets, overdue invoices, customer complaints, or project delays.

The pattern is the same.

Find the place where the owner is manually checking the business every day.

Then start there.

Not every business problem should become an AI project.

Some problems depend on messy data. Some require a larger infrastructure change. Some can deliver value in two weeks. Some sound exciting, but are not actually the highest priority.

That is why AI strategy has to balance impact, speed, complexity, and readiness.

A lot of business owners want to start with the AI tool.

They ask: should we use ChatGPT, Claude, Gemini, an assistant, a dashboard, or a custom system?

That is the wrong first question.

The better question is: where will AI create the most practical value first?

That was the starting point with USA Green Improvement.

Like many growing businesses, the issue was not that they had no systems. They had systems. They had spreadsheets, industry-known platforms, banking data, internal processes, and people who knew how to get things done.

The problem was that the business knowledge was spread across people, spreadsheets, apps, and manual habits.

So the first step was not building software.

The first step was mapping.

We interviewed the people closest to the work. We looked at how work moved across departments, where information stalled, where decisions depended on manual effort, and where better visibility might improve performance.

The team shared screens. They showed how the work actually happened, not just how it was described in theory.

There is often a gap between the process a company believes it has and the process employees actually follow day to day. That gap matters, because AI has to be built around the real workflow, not just the clean version of it.

Once the workflows were mapped, the next step was deciding what to work on first.

For USA Green Improvement, the mapping surfaced multiple areas where AI could support better visibility, faster decisions, and less manual coordination. The important question was not which opportunities existed, but which ones should be addressed first.

There were different paths. One was to start immediately with a focused, high-impact use case. Another was to build stronger data foundations first. A third was to improve department by department and expand over time.

That is the kind of decision businesses often need to make before building anything.

The outcome was a phased roadmap, where each stage could stand on its own and be evaluated before expanding further. Rather than treating AI as one large project, the work was sequenced into manageable steps.

The value of the process was not just identifying where AI might help, but creating a way to decide what to do first, what to defer, and what needed stronger foundations before moving ahead.

For many businesses, that sequencing is as important as the technology itself.

Some companies have a hidden asset that never appears on the balance sheet.

It is not their website. It is not their CRM. It is not their customer list.

It is the knowledge inside the heads of the founder and the team.

That kind of knowledge is hard to see because it does not always look like a product. It shows up in judgment. It shows up in how experienced people make decisions. It shows up in the small details they notice that others miss. It shows up in the way they know what will work, what will fail, and what will create better results.

That is the kind of knowledge this founder had.

His company had developed a way of thinking about its industry that was valuable, but much of that value was locked inside people's brains. It was tribal knowledge. The team knew things that could help others succeed, but the knowledge was not yet packaged in a way the broader industry could use.

That is a very common problem.

A founder becomes an expert. The team learns from the founder. The company develops patterns, frameworks, and instincts. Over time, they know what leads to better outcomes. But unless that knowledge is turned into a repeatable system, it can only travel through conversations, training, consulting, or direct involvement from the expert.

That limits the impact. It also limits the business model.

When knowledge stays trapped inside people's heads, the company can only scale by adding more people, more meetings, more training, and more manual guidance. But when knowledge becomes productized, it can reach more users, more often, with more consistency.

That is the opportunity we are working on with this client.

The goal is not simply to build another AI tool. The goal is to turn expert judgment into a product that can help an industry perform better.

Many AI projects start with a task. The bigger opportunity is asking: what does this company know that the market needs?

For this client, the answer sits in the company's accumulated knowledge. The founder and his team have experience that can improve revenue and performance outcomes for others in the industry. But to make that knowledge useful at scale, it needs structure.

It needs to be captured. It needs to be translated into rules, frameworks, questions, workflows, and decision logic. It needs to become something a user can interact with, not just something an expert can explain.

That is where AI becomes valuable.

AI can help turn expert knowledge into an accessible product layer. It can ask the right questions, guide users through complex decisions, apply the company's logic, and help produce better outcomes based on the knowledge that used to require direct human involvement.

Most experts do not naturally explain how they think. They just think. They recognize patterns quickly because they have seen hundreds or thousands of cases.

Building an AI product around that kind of knowledge requires product strategy: understanding the user, the decision they need to make, the information the expert uses, and the output that would help the user perform better.

When done correctly, the product becomes more than a digital consultant. It becomes a scalable knowledge system that lets the company's expertise travel beyond the limits of the team's time.

For business owners, this raises an important question:

What do we know that could become a product?

If your company has unique knowledge, a proven way of making decisions, or a method that creates better outcomes, that may be your most valuable AI opportunity.

Because AI can help that knowledge travel farther.

For years, most business owners thought they understood Google Workspace.

Gmail was for email. Calendar was for meetings. Drive was for files. Docs was for writing. Sheets was for numbers. Slides was for presentations.

That way of working is becoming outdated.

Google has changed the tools, but more importantly, it has changed the way owners should think about work itself.

With Google Gemini and agents entering the Google ecosystem, the old workflow of opening a blank document, creating a spreadsheet, building a slide deck, and manually searching through folders is no longer the only way to operate.

Business owners and employees need to learn when to use Google Gemini, when to work directly inside Gmail or Docs, when to use agents, how to give better instructions, how to review AI outputs, and how to connect the tool to the real workflow.

That is the biggest shift.

If you need to update a sheet, the work does not have to start with manually editing the file line by line. You can tell the assistant what needs to be updated and use it to help prepare the next steps.

And increasingly, the system can work from context in other documents you direct it to look into. You may ask it to update a sheet using information in project notes, pull details from prior emails before drafting a response, or take a meeting summary and turn it into next steps.

The work starts with direction, not with opening the tool manually.

If you need to find an email, the work does not have to start with searching your inbox and piecing context together yourself. You can ask for the relevant context and continue from there.

If you need to prepare a document or presentation, the starting point does not have to be a blank page. You can give direction, provide context, and have the system help create the first version.

Google tools are becoming less like separate apps and more like a work assistant.

The owner's job shifts from manually creating every piece of work to directing the system, reviewing the output, and deciding the next step.

This requires new habits.

That is why we run consulting and workshops around these tools.

The issue is not whether a company has access to these tools. Many already do.

The issue is whether the team has learned how to work differently with them.

For business owners, this is not only a technology shift. It is a training shift.

Your team needs to relearn how to work with the tools they already use every day.

Google Workspace is no longer just a set of productivity apps.

Used correctly, it becomes a working assistant for the business.

Some RFPs are simple.

Others are dense, technical, and expensive to misunderstand.

For a company in this situation, the challenge was not just writing responses faster. The challenge was quickly understanding whether an RFP was even relevant, whether the company could realistically respond, what technical requirements mattered, and which existing materials could support the answer.

That is exactly the kind of problem NotebookLM is well suited for.

Technical RFPs create a specific kind of burden. They are long. They include detailed requirements. They often reference standards, attachments, specifications, timelines, compliance language, and product capabilities.

Before a team can even decide whether to pursue the opportunity, someone has to read through the material and understand the fit.

NotebookLM helps compress that first review.

The team can load the RFP, supporting documents, past proposals, technical materials, and internal knowledge into one place, then ask direct questions:

Is this RFP relevant to us? What are the mandatory requirements? What are the disqualifiers? Which sections require technical input? Which past answers or documents can support the response? Where might we be missing information?

That makes the first decision faster: should we pursue this or not?

If the RFP is relevant, NotebookLM can then help prepare the response process. It can surface relevant past proposal language, summarize technical documents, compare requirements against internal capabilities, and help generate first drafts for the team to review.

It does not replace the technical expert.

It changes how the expert spends time.

Instead of spending hours searching through files, reading every page from scratch, and copying old answers manually, the expert can focus on judgment: is the answer correct, can we meet the requirement, and should we submit?

For this client, the value was faster RFP qualification, faster response preparation, and better use of expert attention.

For document-heavy teams, tools like NotebookLM can create value quickly because they help turn static documents into usable working knowledge.

In this case, that meant getting to the RFP decision faster and preparing stronger responses with less manual effort.