Show the Output, Not the Feature

Selling AI automation to a service business owner is hard for a specific reason: the product is invisible. You can't point to it. "We automate your workflows" lands with the same thud as "we leverage best-in-class solutions." The owner nods, doesn't know what you mean, and closes the tab.

The standard answer is a feature list. Quote pipeline. Scheduling automation. Job history memory. These are real, but they're still abstract to someone who has never thought about their business in those terms. An electrician running 12 trucks doesn't have a mental model of "quote pipeline." He has a mental model of coming home at 9pm to a stack of estimates he still needs to send.

We tried something different on the /ai page.

The Log

The hero section on /ai has a card in the top right corner. It's styled like a terminal log, monospace font, green checkmarks, dated with today's date. The label says "what your engine did today." The contents:

✓ 7 quote requests received → all drafted, 3 sent
✓ Tomorrow's job sheet built from yesterday's calls
✓ Final invoice sent to Wilson Hardware (job #4427)
✓ 12-day follow-up triggered for 4 estimates that went silent
✓ Tuesday route optimized — saves 47 mi

None of this is real data. There is no Wilson Hardware. The engine didn't save anyone 47 miles today. But every line maps to a real pain that service business owners recognize without translation.

"4 estimates that went silent" is something an HVAC owner has said out loud. Probably this week. "Tomorrow's job sheet built from yesterday's calls" is the thing that currently takes someone an hour on Sunday night. "Saves 47 mi" shows up in routing software output. It sounds like something a system would actually say.

Why This Works

A feature list tells you what a product does. An output log shows you what a day looks like with it running.

The distinction matters because the owner's job is to imagine the future state of their business. Feature lists make that imagination work harder. "Quote pipeline automation" requires the reader to translate the feature into their context: what does that mean for my specific business, my specific volume, my specific problem?

The log skips that translation. The reader sees "12-day follow-up triggered for 4 estimates that went silent" and their first thought is not "I wonder how that works" but "I have 6 of those right now." The product has already landed in their situation before they've read the rest of the page.

The Specificity Signals Legitimacy

"Wilson Hardware (job #4427)" is a detail that would only show up in a real system. Job numbers exist in real operational software. Specific company names show up in real logs. A made-up example would say "Customer A" or "Example Inc." The specificity signals that someone built this and ran it, not just described it.

This is not deceptive. Nobody reading a service page hero thinks that "Wilson Hardware (job #4427)" is a live API call. The terminal aesthetic, the card format, the "what your engine did today" label, all of it frames the content as illustrative. But the specificity inside that frame does real work. It says: we know what this output actually looks like, because we have built it.

The Format Choice

The log lives in a rounded card with a glassmorphism treatment: bg-surface/80 backdrop-blur-sm border border-border. The font is monospace throughout. The checkmarks are in accent blue. The date updates dynamically to today.

The dynamic date is a small thing that matters. It ties the card to the visitor's current moment. It reinforces the "what happened today" framing without requiring any actual data. A static date would feel like a screenshot. "May 25" when today is May 25 feels like a live feed.

The Broader Principle

If you sell a service where the process is complex or invisible, don't describe the process. Show the output in terms the buyer already understands. A plumber doesn't need to know what n8n is. A landscaping owner doesn't need to understand Airtable. They need to see "12-day follow-up triggered for 4 estimates that went silent" and think "I need that."

Your job is not to explain the mechanism. It is to collapse the distance between where they are now and where they would be with your service running.

The log does that in five lines.