The system that learns your shop.

Pull up the CRM you bought four years ago. Open the bid pricing screen. Compare the suggestions it makes today to the suggestions it made the day you turned it on. They are the same. The engine isn't smarter. The engine is the same engine, with four years of your shop's data sitting next to it, completely ignored. That is the deepest problem in the trade software market, and almost nobody talks about it: most software is identical on day 1,000 as it was on day 1. The user has aged. The shop has aged. The customer base has aged. The software has not.

The reason is structural. Most landscape CRMs were built before the modern AI stack existed, and the ones built after were built by teams who wanted to bolt AI onto an existing rolodex without rebuilding the data layer. So the AI got the same generic training every other shop got. Your won bids didn't sharpen the bidding model. Your customer tone shifts didn't sharpen the cancel-detection model. Your urgency signals didn't sharpen the priority engine. The AI was decoration. The shop was the same shop on day 1,000.

The architecture we built does the opposite. Three engines in our system — WinPlaybook, RedFlag, and ToneRadar — get sharper every night on your shop's data, and only your shop's data. After 90 days of running them, the model in your shop is no longer a generic landscape model. It's a model of your shop. And the gap between that model and any pre-built CRM widens every single month, forever.

WinPlaybook — the bid coach that learned your customers

Every bid your shop has ever won is a data point about which combinations of property, season, customer type, and price actually close in your market. WinPlaybook reads those data points every night and refines a bid-suggestion model that is uniquely yours. Day one, it makes generic suggestions in line with industry benchmarks. Day thirty, it has noticed that you win commercial mow contracts in your zip code at a 11.6% premium to industry baseline. Day sixty, it has noticed that residential hardscape jobs over $9,800 in your customer base have a 47% close rate when the bid is delivered within 48 hours and an 18% close rate after that. Day ninety, it is suggesting bid prices to your sales person that are tighter than anything a generic CRM could ever offer, because they're tuned to the won bids your shop has produced — not the won bids of every shop in America averaged together.

And it keeps going. Day 180. Day 360. Day 720. Every quote your shop generates teaches it more about your customers, your seasons, and your market. The model in your shop on day 720 is not just better than the day-one model. It's better than the model any new shop on the system has access to, including new shops in your market — because their data isn't yours.

RedFlag — the urgency engine that learned your inbound

Every inbound to your shop carries an urgency signal. Some of those signals are obvious — the word emergency, the phrase asap, the storm-damage photo attached to the email. Most of them aren't. The signal that a particular property manager always emails on Tuesday and always closes within 72 hours when she emails on Tuesday is a signal that no generic urgency model has any way to know. The signal that a residential customer who emails after 9 PM on a weeknight has a 3x higher close rate than one who emails midday is also unique to your shop. RedFlag learns those signals. Every night.

Day one, it flags the obvious — the storm photos, the asap text. Day thirty, it has started to notice your shop's specific timing patterns. Day sixty, it knows that the property manager at 7910 always closes on Tuesdays and is treating her inbound as a top-tier flag. Day ninety, it is sequencing your inbound by a model of urgency that the office manager could not produce on her best day, because the model has access to four months of patterns that no human is going to hold in their head. The crew is responding to the right inbound first. The wrong inbound is not getting ignored — it's getting handled at the cadence it actually deserves. The shop is no longer paying full price for marketing and capturing a tenth of the revenue, because the inbound triage is no longer a coin flip.

ToneRadar — the early-warning system that learned your customers

ToneRadar reads every inbound email and text from every customer and tracks the tone shifts. The customer who used to write back in three lines and a thumbs-up, and is now writing back in two lines with no punctuation, is shifting tone. The customer who used to thank the crew and is now sending a one-word reply is shifting tone. The customer whose payment used to clear in two days and is now clearing in nine is shifting on a different axis, but the model reads that one too. The patterns of tone shift that precede a cancel are not generic — they are specific to the customer base you've built, and they are specific to your shop's voice in those threads.

Day one, ToneRadar flags the explicit signals — the word frustrated, the word disappointed, the phrase looking around. Day thirty, it has started to detect the punctuation drops, the brevity shifts, the latency changes. Day sixty, it has built a tone-shift model specific to your customers — and it is feeding that model into Save Play, which is now triggering interventions three to nine weeks earlier than your office manager would on her best day. Day ninety, your save rate on at-risk customers has roughly doubled, because you stopped trying to save them in the week of the cancel and started saving them six weeks before they ever wrote the cancel email.

Why competitors freeze on day 1

The legacy CRMs in this market were built on a data architecture that treats every customer as a row in a static table. The AI features bolted onto those products are AI features that run against generic, cross-tenant training data — they have to, because the per-tenant data is too thin and too inconsistent to train against, and the products were never built to do nightly per-tenant model refresh. The result is that every shop using those CRMs is using the same model. The shop with twelve crews and eighty thousand customers is getting the same suggestions as the shop with one truck and a hundred and forty customers. Both shops' AI is frozen on day one of when the vendor last shipped a model update.

Our architecture refuses that. Every shop has its own per-tenant model layer. Every night, your shop's data trains your shop's models. The architecture cost more to build, takes more compute to run, and is the reason we shipped thirty-three engines instead of eight. It is also the reason we will keep widening the gap on legacy CRMs every month for the foreseeable future. They are not going to rebuild their data layer to do this. The capital cost is too high, and the install base they would have to migrate is too painful. Their answer is going to be to add a chatbot. Our answer is going to be a system that knows your shop better every day.

What 'a system that learns your shop' actually feels like

Owners running our pilot for ninety days describe it the same way. They stop opening the morning bid screen to check pricing — they trust WinPlaybook's suggestion now. They stop checking the inbound queue at lunch — RedFlag has already prioritized it. They stop reading every customer email on Sunday night — ToneRadar has flagged the three that need an owner call before Tuesday. The mental load drops. The decision quality goes up. And the customer base feels differently — customers who used to drift to cancel are getting saved at a higher rate, customers who used to wait three days for a quote are getting one in three hours, customers who used to feel like a row in a database are getting a system response sized to their actual value.

The owner is no longer the bottleneck on the soft judgment calls. The system has been quietly studying her shop for ninety days, and now the system has an opinion. The owner can override it. She does, sometimes. But the override is the exception, and the system gets sharper every time she does, because the override teaches it. By day 180, the override rate has dropped by half. By day 360, the system is doing the work of an experienced sales coordinator and a half-time customer success manager, and the wage cost of those two roles is being held in software that costs less than half of one of them.

The compounding bet

Here is the bet. The legacy CRMs will keep shipping the same model on day 1,000 as day 1, because their architecture forces that. We will keep shipping a model that's sharper every month, because our architecture forces that too. The gap is small at day thirty. It is meaningful at day ninety. It is structural at day three hundred and sixty. By the time a shop has been on our system for two years, switching costs are not about the data export — they are about the two years of model sharpening that walk out the door if the shop leaves. That is what compounding looks like in software. We didn't invent it. ServiceTitan didn't invent it either. But every category leader in software for the last twenty years has had it, and every laggard hasn't.

If this lands, the next move is to see what your shop's day-90 model would look like against your real numbers. Pull up the ROI page and run the inputs. Or if you're closer to ready than that, apply to the Council — the founding cohort gets locked-in pricing for the life of the account, and the model your shop builds in the first 90 days stays your shop's model, forever. Either way, the gap is opening every day. The longer you wait to start the ninety-day clock, the further behind your competitors who already started it.