It's 7:14 a.m. on a Tuesday in May. A branch manager at a $42M landscape company opens her laptop. Five tabs. Aspire, to pull last week's hours. NetSuite, to check job costing. Fleetio, to see which trucks rolled. ADP, to confirm a payroll question. Her own Google Sheet, because none of the four systems above answer the question her CEO just texted her about: "why are crews 4 through 7 trending 23% over plan?"
She'll spend the next forty-five minutes copying numbers between tabs. She'll get an answer by 9 a.m. By then, three more questions will be in her inbox.
This is the landscape industry's actual software problem. And it's not the problem most people are trying to solve.
TL;DR
- The commercial landscape industry doesn't have a tools shortage. Every category is now well-covered.
- It has a connection shortage. The average $20M+ landscape company runs six to eight systems that don't talk to each other.
- The two common responses, dashboards on top of one system and a new "all-in-one" platform, both leave the real problem in place.
- The fix is an intelligence layer underneath the stack you already run. A layer that reads everything, remembers everything, and answers anything.
- It's the only architecture that scales without adding another seat to log into.
You don't have a tools problem. You have a connection problem.
Walk into the back office of any growing landscape company and ask the operations lead what they need. You will hear answers like "better job costing", "a real CRM", "fleet visibility", "a way to make site walks actually mean something."
Look closer and you'll notice something. They already have all of those things. The job-costing module is in Aspire. The CRM is in Aspire too, or NetSuite, depending on the year it was bought. Fleet visibility lives in Fleetio or Samsara. Site walks happen on a half-dozen crew phones and end up nowhere in particular.
The systems exist. They were chosen carefully. They each work fine inside themselves. The problem is that nothing crosses the boundaries between them. The data sits in islands. The questions an operator actually asks, "which properties are at risk of renewal slippage given last week's site walks?", require crossing four of those islands at once.
That's not a software-feature problem. That's an architecture problem.
The eight-system reality
Most commercial landscape companies in the $20M to $200M range now run something like this:
| Layer | Typical system(s) |
|---|---|
| ERP / accounting | Aspire, QuickBooks, NetSuite |
| Job costing | Aspire (sometimes a separate spreadsheet) |
| CRM / sales | Aspire, Salesforce, HubSpot, NetSuite |
| Email + calendar | Gmail or Outlook |
| Documents + SOPs | Google Drive, SharePoint, a network share |
| Field capture | Phone photo libraries, WhatsApp, sometimes a real app |
| Weather + maps | Off-the-shelf consumer apps |
| Equipment + telematics | Fleetio, Samsara, OEM systems |
| Vendors + pricing | Spreadsheets, a buyer's email inbox |
That's nine boxes. Most companies are running six to eight of them. None of those boxes were designed to talk to the others. Worse, several of them, the dominant ERPs in particular, have business reasons not to be easy to integrate into. The vendor that owns your data has leverage. The vendor that hands it off doesn't.
This is the integration debt. It compounds quietly every quarter. Every new system added to the stack adds another bridge that nobody builds.
What the two common fixes get wrong
Two playbooks dominate the response to this problem. Both fall short, in instructive ways.
Playbook 1: dashboards on top of one system. A vendor builds a beautiful business-intelligence layer on top of Aspire (or whichever ERP dominates). Penetration trends, renewal pipeline, AI-recommended actions on the accounts that look risky. These tools are useful. They make the data already in Aspire prettier and more legible.
The limit is right there in the architecture: they read one system. The renewal-pipeline question that also needs the last twelve weeks of site walks, the weather pattern across those properties, and the email thread with the customer can't be answered by a dashboard sitting on Aspire alone. The data isn't in Aspire.
Playbook 2: another operating system. A vendor builds a new all-in-one platform that tries to replace some or all of the existing stack. "Move everything onto our OS and we'll handle the rest." This is the rip-and-replace bet.
The honest math: a $50M landscape company has been on Aspire for eight years. Their team knows it. Their integrations to payroll and accounting are wired through it. Their last three years of job-costing history lives in it. They are not ripping it out for a younger product, no matter how good. They can run a parallel platform for one workflow, but they cannot, and will not, replace the system of record.
So both playbooks leave the same problem in place. Dashboards see only one island. New OSes assume you'll abandon the others. The connection problem doesn't get solved either way.
What an intelligence layer actually is
The architecture that does solve it is a different shape. Call it an intelligence layer. It sits underneath every system you run today and reads from all of them.
A real intelligence layer has three properties that distinguish it from a dashboard or an OS:
It is system-agnostic. It connects to Aspire, NetSuite, Fleetio, ADP, your email, your shared drive, your weather feed, and the photo your crew lead just took on a property, and it understands that they are all describing the same company. The boundaries between systems become invisible to the operator asking the question.
It has memory. It doesn't just answer the question you asked this morning. It remembers what answer it gave you last quarter, what changed since, which properties keep showing up in the same kind of alert, which crew leads are consistently flagged in the same way. The longer it runs, the smarter it gets, because every snap, huddle, ticket, and correction feeds back into the same context.
It can act, not just report. Reporting tells you what happened. An intelligence layer drafts the proposal, queues the schedule shift, alerts the manager, books the equipment service. Visibility is necessary but not sufficient. The operator's time is worth more than another dashboard to scroll through.
This is the architectural bet behind what we're building at HeyFlora. We call ours the Mycelium Intelligence Layer, the connective tissue under the stack you already run, with Flora as the queryable surface on top. The metaphor is deliberate: mycelium is the underground network that connects every plant in a forest into one organism. Same idea here. Your systems stay where they are. The intelligence layer makes them behave as one.
You can see how it works in practice on the platform page, and the deeper architecture, the six primitives that make an agent reliable enough to act on real money, is laid out in the execution-layer page.
Three questions to audit your own stack this week
If you want to test whether your business has a tools problem or a connection problem, ask these three questions on Monday morning.
1. What's the simplest cross-system question your operations lead can't answer in under five minutes? Try: "Show me every property whose hours are over plan AND whose last site walk flagged irrigation issues." If the answer takes more than five minutes, the connection problem is real and quantified.
2. How many places does the same fact live? Count how many times your most-used property name appears across systems: Aspire, your shared drive folder, three crew leads' phones, an email thread. Each duplicate is a maintenance tax and a future contradiction.
3. When you add a system, do the existing ones get smarter? The right answer is yes. If adding a new tool just adds another tab and another login, the architecture is wrong. New systems should compound into the intelligence layer, not pile up next to it.
If two of those three answers come back ugly, the problem isn't that you're missing software. The problem is that you haven't put a layer underneath the software you already have.
What's coming
In the next post in this series I'll walk through the architecture of agents themselves: what makes an "AI agent" actually different from a feature, why memory and evaluation are the parts most vendors skip, and what an operator should look for before trusting one to draft a proposal or queue a schedule change.
For now: if any part of this post sounded like the conversation you've been having with your ops lead for the last six months, you're not missing a tool. You're missing a layer.
Scott Hutcheon is the founder and CEO of HeyFlora. He's spent twenty-five years in design-build, green infrastructure, and landscape technology. HeyFlora is building Artificial Grounds Intelligence™, the AI operating system for commercial landscape.
Get the next Field Note in your inbox: Subscribe to Grounds Intelligence Weekly.