Tag: Brand Operating System

  • Notion Isn’t the Everything App. It’s the Everything Database — and That’s a Better Bet.

    Notion Isn’t the Everything App. It’s the Everything Database — and That’s a Better Bet.

    Last refreshed: May 15, 2026

    Update — May 15, 2026: On May 13, 2026, Notion shipped the Notion Developer Platform (version 3.5), with Claude as a launch partner. The platform adds Workers, database sync, an External Agents API, and a Notion CLI. For the full breakdown of what changed and what it means for the Notion + Claude stack, see Notion Developer Platform Launch (May 13, 2026). For the underlying operating philosophy, see The Three-Legged Stack: Notion + Claude + Google Cloud.

    Everyone is building the everything app. Microsoft wants to be yours. Google wants to be yours. Notion wants to be yours. But there’s a fourth path nobody is talking about — and it might be the smartest play for brands, agencies, and multi-system operators: don’t pick one everything app. Build one everything database, and let it feed all of them.

    The Core Idea Notion isn’t competing to be your everything app. It’s competing to be your everything database — the structured, queryable, agent-ready source of truth that sits underneath whatever surface you use. The everything app becomes interchangeable. The database is the moat.

    The Series So Far — and Why This Frame Changes Everything

    This is the fourth piece in a series examining who wins the everything-app race. We looked at Microsoft stitching together an everything app through acquisitions, Google trying to unify a native stack it keeps fragmenting, and Notion building from the database up. Each piece treated the everything app as the destination.

    But there’s a reframe worth making. What if the everything app isn’t the destination? What if the destination is the data layer underneath it — and the everything app is just whichever surface happens to be most useful at a given moment?

    That’s the angle that emerged from actually building inside Notion Workers alpha. And it changes the strategic calculus significantly for anyone running a brand, an agency, or a multi-system operation.

    Your Brand Doesn’t Need One Everything App. It Needs One Everything Database.

    Think about what an everything app actually requires to work. It needs to know your tasks. Your projects. Your contacts. Your content calendar. Your pipeline. Your team’s status. Your historical decisions. Your brand voice. Your client relationships. Your automation outputs.

    That’s not an app problem. That’s a data structure problem. And the company that solves the data structure problem — that gives you a clean, typed, queryable, agent-ready home for all of that — wins, regardless of which surface you use to view it.

    Notion’s database architecture is purpose-built for exactly this. Every property is typed. Every row is queryable. Every database can be filtered, sorted, related, and rolled up. When you build your brand’s operational data inside Notion — tasks with statuses, projects with owners, content with metadata, contacts with relationship history — you’re not just organizing. You’re building a structured intelligence layer that agents can read, write, and reason over reliably.

    That database doesn’t care which “everything app” sits on top of it. Microsoft Copilot can query it. Google Workspace agents can sync from it. Your own custom dashboard can read it via the Public API. Claude can operate on it directly. The surface is interchangeable. The database is the thing that compounds in value over time.

    The 30-Second Trigger: Where the Architecture Gets Interesting

    Here’s the piece that came out of our own Workers alpha experience — and it reframes the “30-second sandbox limitation” from a constraint into a feature.

    Notion Workers runs in a 30-second execution window. We hit that wall hard when we tried to move heavy automations — multi-site WordPress optimization passes, content pipelines, image generation — into Workers. Those are multi-minute jobs. They don’t fit.

    But 30 seconds is more than enough to do one specific thing: fire a signed HTTP POST to an external endpoint and return.

    That’s the architectural insight. You don’t use Notion Workers to execute heavy work. You use Notion Workers to trigger it. The Worker wakes up — on a schedule, on a database change, on a webhook — reads the relevant Notion database row, constructs a signed payload, fires a POST to a Google Cloud Run job, and exits. The whole thing takes under five seconds. Well within the 30-second window.

    Cloud Run picks up the job, runs for as long as it needs — minutes, not seconds — and when it’s done, it writes the results back to the Notion database via the Public API. The Notion database is now the job queue, the status tracker, the results store, and the orchestration log. All in one place. All queryable by agents.

    The pattern in practice:

    Notion Worker (cron / DB change / webhook)
      → reads Notion database row for job config
      → signs POST to Cloud Run endpoint
      → returns immediately (3–8 seconds, well under 30s)

    Cloud Run (no time limit)
      → runs heavy job (WP optimization, pipeline, image gen)
      → writes status + results back to Notion DB via Public API

    Notion Database
      → job queue / status tracker / results store / audit log
      → queryable by agents, visible to team, triggerable again

    This is the hybrid architecture we’re running. Our Tuesday 18-site WordPress SEO optimization pass runs on Cloud Run — not because Notion can’t orchestrate it, but because Notion does orchestrate it, as the database layer, while Cloud Run handles the execution. The Worker is the tickle. Cloud Run is the muscle. Notion is the brain that remembers everything.

    What “Brand Everything Database” Actually Means in Practice

    If you’re an agency, a media operation, or a multi-brand operator, here’s the concrete version of this architecture:

    • One Notion workspace as the brand OS. Every client, project, task, content piece, automation job, and decision lives as structured database rows. Not documents. Not folders. Typed, relational data.
    • Agents inside Notion prep the data. Custom agents compile status updates, flag stale work, surface blockers, build briefings — all operating on the Notion database directly. The “everything” data is always clean and current because agents are maintaining it continuously.
    • Workers trigger external execution. When a job needs more than 30 seconds — content pipelines, SEO runs, bulk operations — a Worker fires the trigger. Cloud Run executes. Results come back into Notion. The database stays the source of truth.
    • Any surface can consume it. A Copilot user can query the project database through Microsoft Graph connectors. A Google Workspace user can sync from Notion via the connector ecosystem. A custom dashboard can read the Notion API. The front end doesn’t matter. The database is always current.
    • External agents get full context. Through the External Agents API, Claude, Codex, or any agent you build can operate against your Notion databases with complete organizational context — not a generic AI, but one that knows your specific data, your specific projects, your specific brand.

    Why This Beats Betting on One Everything App

    The everything-app race has a winner-take-all framing that may be wrong. Here’s what we’ve observed from operating across Microsoft, Google, and Notion simultaneously:

    Different team members live in different surfaces. Your developer lives in GitHub and a terminal. Your account manager lives in Gmail. Your ops lead lives in a spreadsheet. Your creative lead lives in Figma. Forcing everyone onto one everything app means fighting human behavior, not working with it.

    But if everyone’s work — regardless of where they do it — writes back into a shared Notion database? The everything app problem disappears. You don’t need everyone in the same surface. You need everyone’s data in the same structure.

    That’s what Notion’s connector ecosystem is actually building toward. GitHub syncs into Notion. Jira syncs into Notion. Salesforce syncs into Notion. Slack syncs into Notion. The surface stays wherever it is. The intelligence layer centralizes.

    The Compounding Advantage

    Here’s the strategic reason this matters beyond the technical architecture: databases compound. Documents don’t.

    A Google Doc from two years ago is mostly dead weight — hard to search, hard to query, impossible for an agent to reason over reliably. A Notion database from two years ago is a living asset. Every row is still queryable. Every relationship still works. The history of every project, every decision, every outcome is structured data that an agent can analyze, pattern-match against, and use to inform current work.

    The longer you run your brand’s operations through a Notion database, the smarter your agents get — because they have more structured history to work with. That’s not true of any document-first system. And it’s not something you can easily replicate once a competitor has two years of structured operational data and you’re starting from scratch.

    The everything app you pick in 2026 matters less than the data structure you commit to in 2026. Pick the wrong everything app and you switch in 18 months. Pick the wrong data structure and you’re rebuilding from zero.

    The Practical Starting Point

    If this architecture makes sense for your operation, here’s how to think about the starting point:

    • Audit what data your business actually runs on. Tasks, projects, clients, content, pipelines, automations — map out what you’re currently tracking and where. How much of it is in documents? How much is in structured databases?
    • Pick the three databases that matter most and build them right in Notion. Don’t try to migrate everything at once. Start with your project tracker, your content calendar, and your client/contact database. Get those typed, relational, and agent-ready.
    • Connect one external source via Workers or the connector ecosystem. Slack, GitHub, Jira — pick the one that generates the most signal for your operation and get it syncing into Notion.
    • Build one Custom Agent that works on those databases. A status compiler, a blocker detector, a briefing builder — something that demonstrates the database-first advantage concretely to your team.
    • Then consider the trigger pattern. What jobs in your operation take longer than 30 seconds but could be triggered from a database change? Those are your first Cloud Run candidates, with Notion as the orchestration layer.

    The everything app race is real. But the more durable competitive advantage is the data structure underneath it. Build the database right, and the everything app becomes a detail.

    Frequently Asked Questions

    What is a “brand everything database” in Notion?

    A brand everything database is a Notion workspace architected as the structured, queryable source of truth for all of a brand’s operational data — tasks, projects, content, clients, automations, decisions. Unlike document-based systems, every piece of information is typed, relational, and agent-readable. External tools sync into it; agents operate on it; any surface can consume it via the Public API.

    How do Notion Workers act as triggers for Google Cloud Run?

    Notion Workers run in a 30-second sandbox — enough time to read a Notion database row, construct a signed payload, and fire an HTTP POST to a Cloud Run endpoint. The Worker returns immediately; Cloud Run handles the long-running execution (minutes, not seconds) and writes results back to the Notion database via the Public API. This makes Notion the orchestration and visibility layer without hitting the sandbox time limit.

    Why is a database-first architecture better than document-first for AI agents?

    Documents require AI to infer structure from prose — an error-prone process that degrades at scale. Database rows are typed, structured, and directly queryable. An agent asking “which projects are blocked this week?” gets an exact filter result from a Notion database in milliseconds; the same question against a folder of Google Docs produces a best-effort summary. Reliability and precision are the key differences.

    Can Notion databases feed Microsoft Copilot or Google Workspace agents?

    Yes, via connectors and the Notion Public API. Microsoft Graph connectors and Google Workspace connectors can sync from Notion databases. Custom agents built on the External Agents API can also read and write Notion data from any external platform. The Notion database becomes the shared source of truth regardless of which AI surface your team prefers.

    What’s the best first step to building a brand everything database in Notion?

    Start with three core databases: a project tracker, a content calendar, and a client/contact database. Get them typed with proper properties, linked relationally, and cleaned up. Then build one Custom Agent that operates on those databases — a status compiler or briefing builder. Once you’ve seen the database-first advantage in action, the architecture for connecting external tools and Cloud Run triggers becomes obvious.

  • The New Restoration Operator: How the Industry’s Best Companies Are Thinking in 2026

    The New Restoration Operator: How the Industry’s Best Companies Are Thinking in 2026

    This is the pillar piece for The Restoration Operator’s Playbook — Tygart Media’s body of work on how the industry’s best restoration companies are actually thinking in 2026. Every cluster article on this site links back to this one. If you only read one piece of operational intelligence about restoration this year, read this.

    The industry is splitting in two

    If you run a restoration company in 2026, you can feel it even if you can’t name it yet. Something has changed in the last eighteen months. The companies you used to compete with on price are starting to look operationally different. The owners you grab a drink with at conferences are talking about things that didn’t exist as topics two years ago. The carriers are quietly recalibrating who they trust with what kind of work, and the criteria they’re using don’t always show up in TPA scorecards.

    The industry is splitting in two. Not by size. Not by geography. Not by certification. The split is happening along a single axis: how seriously the company has thought about the difference between doing the work and operating the system that does the work.

    Companies on one side of the split still think of themselves as a collection of trucks, technicians, and jobs. They get up every morning and chase the work that came in the night before. They are very good at the work itself. Their PMs are senior, their crews are loyal, their relationships with adjusters are warm. They have been profitable for fifteen or twenty years doing exactly what they have always done.

    Companies on the other side of the split think of themselves as a system. The work is the output, not the identity. They invest in the operating layer — documentation, decision frameworks, training architecture, technology, talent development — at a rate that looks excessive to their peers. They are not necessarily larger. They are not necessarily growing faster on the top line. But over a five-year window, the gap between the two groups becomes severe and, eventually, irreversible.

    This is the playbook for the second group. It is also a warning to the first.

    Why this is happening now

    Restoration has always been an industry where tribal knowledge created a moat. A senior project manager who has worked five hundred losses knows things that have never been written down anywhere. The judgment that separates a profitable mitigation job from a money-losing one — when to recommend pack-out, how aggressively to demo, which sub to call for which kind of structural drying problem, how to read an adjuster’s tone on the first call — none of that lives in a textbook. It lives in the heads of people who have been doing the work for a long time.

    For most of the industry’s history, that fact was a feature. The senior PM was the asset. The owner who hired and retained the best PMs ran the best company. Period.

    That equation is changing in 2026. It is not changing because senior PMs matter less. They matter more than ever. It is changing because, for the first time, that judgment can be encoded into systems that the rest of the company can run.

    The pieces have been arriving in stages. Cloud documentation made it possible to actually capture what senior operators do. Generative AI made it possible to interrogate that documentation at speed and turn it into decisions. And in early 2026, the infrastructure layer that lets companies build and run autonomous workflows on top of all of it became a managed service. The work that used to require a six-month engineering project is now a configuration question.

    What this means in practice is that the value of a senior operator is no longer just the work that operator does directly. It is the work an entire system does in their image once their judgment has been captured and encoded. A senior PM whose decision-making becomes the substrate for how the rest of the company handles initial response, scope decisions, sub assignments, and customer communication is worth something different — and something larger — than the same PM doing the work themselves.

    The companies that understand this are quietly buying senior talent at the current price and treating that talent as the raw material for the operating system they are about to build. The companies that don’t understand it are still treating senior PMs as line-level production units, which means they are about to overpay for talent in twenty-four months when the rest of the industry catches up to the repricing.

    The mitigation-to-reconstruction problem

    To make any of this concrete, start with the single most expensive operational decision in the entire restoration economic chain: how mitigation gets handed off to reconstruction.

    It is also one of the least understood, because most companies live on one side of the handoff or the other. Mitigation-only firms see their job as ending at dryout. Reconstruction-only firms see their job as starting from whatever the mitigation team left behind. Both groups treat the handoff as a logistics problem when it is actually an economics problem, and the economics are brutal.

    A mitigation team that demos too aggressively makes the rebuild more expensive than it had to be — which means the homeowner runs out of coverage faster, which means fewer upgrades, which means a less satisfied customer at the close-out. A mitigation team that demos too conservatively leaves moisture or structural damage hidden, which means rework on the rebuild side, which means the carrier eventually pushes back on the file and the reconstruction company eats the difference. A mitigation team that documents poorly leaves the reconstruction estimator guessing, which costs days on every job and creates scope arguments with the adjuster that didn’t have to happen. A mitigation team that doesn’t think about flooring transitions, baseboard seams, ceiling textures, or trim profiles before they cut creates rebuild work that takes longer and looks worse than it should.

    Each of these decisions individually is small. In aggregate, across thousands of jobs per year, they determine whether a regional restoration company is running on twelve percent net margin or twenty-two percent net margin. They determine how many homeowners write the company a five-star review. They determine whether the carrier sends the next loss to this company or to a competitor.

    And almost none of it is taught. Mitigation crews are trained to dry the building. Reconstruction crews are trained to put it back together. The interface between the two — the layer where the actual money is made or lost — is treated as someone else’s problem on both sides.

    The companies that have figured this out have done one of two things. Either they have brought both functions in-house and built the handoff into a single operational system, or they have built deliberate mitigation prep standards and trained their subcontractor mitigation partners on them. Both moves reflect the same underlying insight: the company that owns the end of the job has to own the beginning of the job, because every decision at the beginning is a vote about what the end is going to look like.

    Stephen Covey called it beginning with the end in mind. In restoration it is not a personal development principle. It is a profit and loss statement.

    Senior talent is the new force multiplier

    If the operating layer is the new battleground, senior talent is the new force multiplier. This is the part of the playbook most owners are still pricing wrong.

    For the last two decades, the math on a senior project manager looked roughly like this: the PM produces a certain volume of revenue per year, the company keeps a certain percentage of that revenue as gross margin, the PM costs a certain salary plus benefits, the difference is the contribution. Owners who could do that math could decide how many senior PMs to hire and how much to pay them.

    That math is now incomplete. The senior PM is no longer just a producer. The senior PM is a teacher whose judgment, once captured, runs across every job the company touches — including jobs the PM never personally sees. The contribution from a single senior operator is no longer linear. It compounds.

    Owners who are running on the old math are about to be outbid for senior talent by owners who are running on the new math. This is happening already in pockets of the industry, especially in metro markets where private equity has begun to show up. A senior PM who would have been worth $140,000 in 2023 is worth something materially higher to a buyer who plans to use that PM as the architect of an operational system. The market hasn’t fully repriced yet. The arbitrage window for owners who move now is real and finite.

    This also reframes recruiting as a strategic function rather than a HR function. The recruiter who knows which senior operators in a market are quietly thinking about a move, who understands what a sophisticated buyer is willing to pay, and who can credibly explain to a candidate what the next chapter of the industry looks like, is operating at a different altitude than the recruiter who is filling seats off a job board. Owners who haven’t built that recruiting relationship yet are starting from behind.

    The new operating stack

    The companies pulling away from the pack are building what amounts to a new operating stack. It does not show up on the org chart. It rarely shows up in conference presentations because the operators running it know that the longer they keep quiet, the longer the lead lasts. But the pattern is consistent enough across geographies and company sizes to describe.

    The first layer is documentation. Not policy manuals — those have always existed and rarely change anything. The new documentation is operational decision capture. How do our best PMs decide whether to recommend pack-out. How do they decide when to push back on an adjuster’s scope. How do they handle the customer conversation when an estimate comes in higher than expected. The documentation lives in a structured system that can be queried, not a binder on a shelf.

    The second layer is structured training built on top of that documentation. New hires don’t shadow a senior PM for a year hoping the right situations come up. They work through structured scenarios drawn from the actual decision capture. The senior PM’s time is leveraged across the whole training cohort instead of being burned on one apprentice at a time.

    The third layer is technology — but the technology only works because the first two layers exist. AI systems are extraordinary at applying captured judgment to new situations. They are useless at inventing judgment that was never captured. Companies that have spent two years building decision documentation can plug in modern tooling and get force multiplication immediately. Companies that haven’t done the documentation work are buying tools they cannot effectively use, which is why so much restoration software ends up shelved.

    The fourth layer is financial operations discipline that matches the operating discipline. Job-level WIP tracking, real-time margin visibility, scope-change accountability, sub performance scorecards. The reason this layer matters is that the first three layers will surface problems faster than the company can act on them unless the financial visibility is in place. Operating clarity without financial clarity creates frustration. The two have to move together.

    Most companies in the industry have one of these layers. A few have two. A small number have three. The companies that have all four are the ones running away from the pack, and they know exactly what they have.

    What this means for owners

    If you own a restoration company and you have read this far, the implication is uncomfortable. The decisions you make in the next twelve to twenty-four months matter more than the decisions you have made in the previous five years. The window in which the operating-system advantage can still be built at a reasonable cost is open now and will not stay open.

    This does not mean you need to spend a million dollars on technology. It means you need to be honest about which of the four operating layers your company actually has, and which it doesn’t. It means you need to identify the two or three senior operators whose judgment is load-bearing for your business and start the documentation work — not in a way that scares them about being replaced, but in a way that respects them as the architects of the next chapter. It means you need to look at your senior hire roster and decide whether you have one or two more PMs you should be courting now, while the market hasn’t fully repriced. It means you need to think about your mitigation-to-reconstruction handoff with the seriousness it deserves, whether you own both sides or you partner.

    It does not mean you need to do everything at once. It means you need to start. The companies that have already started have a head start that compounds every quarter.

    What this means for senior operators

    If you are a senior PM, GM, or estimator reading this, the implication is different. Your value is rising. Not in the abstract, sociological sense. In the concrete, dollars-on-the-table sense. The owners who understand the new math are looking for people like you, and the recruiters who serve those owners are looking on their behalf.

    This is also a moment to think about what you actually want the next chapter of your career to look like. Some senior operators are happiest doing the work they have always done in a company they have always loved. That is a perfectly reasonable choice. Others are at a stage where they would rather use their two decades of judgment to architect how a whole company operates instead of personally running fifty jobs a year. That is now a real option in a way it was not five years ago. The companies that need that kind of architect are willing to pay for it, and they are increasingly easy to find if you know who is asking.

    What this means for the rest of the industry

    For the carriers, the TPAs, the manufacturers, and the trade associations, the implication is structural. The contractor base you are working with is going to bifurcate over the next thirty-six months. The companies on the operating-system side of the split are going to be more reliable, faster on cycle time, more accurate on documentation, and less prone to the disputes that eat your time. They are also going to expect to be treated differently than the rest of the panel. The companies on the other side of the split are going to look increasingly fragile by comparison, and the cost of working with them — in time, in disputes, in customer satisfaction — is going to become harder to justify.

    The smart move for everyone in the broader ecosystem is to start identifying which contractors are building the operating system and which are not, and to design programs and incentives that pull more of the industry toward the first group. The contractors who have built it will reward partners who recognize them. The contractors who haven’t will need help getting there, and the partners who help them will own those relationships for a decade.

    Why we are publishing this

    Tygart Media is publishing this body of work for one simple reason. The restoration industry is going through the most consequential operational shift it has experienced in a generation, and most of the people inside it do not yet have a vocabulary for what is happening. The owners are feeling it. The senior operators are feeling it. The carriers are feeling it. But the conversation has not caught up to the reality.

    This pillar — and the cluster of articles that will be published under it over the coming months — is an attempt to give the industry that vocabulary. To name what is changing. To make it possible for owners and operators to think clearly about decisions that, until now, they have been making on instinct in a fog.

    We do not name companies in this work, ours or anyone else’s. Naming companies turns intelligence into marketing, and the moment that happens the work loses its usefulness. What we publish here is meant to be useful first. Operators should be able to read it and act on it without having to filter out a sales pitch.

    The companies that figure this out will not need to be told who is publishing the playbook. They will already know.

    Cluster articles published in this series

    Mitigation-to-Reconstruction Intelligence (full cluster)

    1. The Mitigation-to-Reconstruction Handoff: Where Restoration Companies Quietly Lose Half Their Margin
    2. The Documented Mitigation Prep Standard: The Operational Artifact Almost No Restoration Company Actually Has
    3. Photo and Documentation Discipline for Two Audiences: Mitigation’s Most Underrated Operational Lever
    4. The Feedback Loop That Keeps a Mitigation Prep Standard Alive — and Why Most Companies Skip It
    5. The Shared Scoreboard: Why Mitigation and Reconstruction Need One Number They Both Own

    AI in Restoration Operations (full cluster)

    1. Why Most Restoration AI Projects Fail — and What the Few That Work Have in Common
    2. What to Build First: The Restoration AI Sequencing Question Most Owners Get Wrong
    3. The Senior Operator Is the Source Code: A Frame for Restoration AI That Changes the Math on Hiring, Retention, and Documentation
    4. The Economics of Agent-Assisted Restoration Operations: The Cost-Structure Shift That Will Decide Who Is Profitable in 2028
    5. How to Evaluate Restoration AI Tools Without Getting Fooled: The Buyer Framework for a Difficult Vendor Environment

    Senior Talent as Force Multiplier (full cluster)

    1. The Restoration Talent Window Is Closing Faster Than You Think
    2. The Senior Restoration Operator Compensation Question: Why the Old Math Is Producing the Wrong Numbers in 2026
    3. Recruiting as a Strategic Function: Why Restoration Senior Hiring Has Outgrown the HR Setup
    4. Retention When the Operator Has Been Documented: Why Traditional Retention Math No Longer Captures the Stakes
    5. Building the Senior Restoration Career Path: The New Roles That Are Keeping Senior Talent in the Industry

    End-in-Mind Operations (full cluster)

    1. The End-in-Mind Principle in Restoration: What Covey Actually Meant for Service Businesses
    2. The Close-Out Test: A Cognitive Practice for Applying End-in-Mind Thinking to Real Restoration Decisions
    3. The Customer Lifetime Frame: Why the Restoration Job Is the Beginning of the Relationship, Not the End
    4. End-in-Mind Subcontracting: How the Companies You Pair With Determine What Your Customer Remembers
    5. The Owner’s End-in-Mind: Building the Restoration Company You Want to Hand Off, Sell, or Be Proud of in Twenty Years

    Carrier & TPA Strategy (full cluster)

    1. The Carrier Relationship as Strategic Asset, Not Operational Burden
    2. Scope Discipline: How the Best Restoration Companies Defend Their Numbers Without Burning the Carrier Relationship
    3. The TPA Game: Understanding What Third-Party Administrators Actually Optimize For
    4. Program Standing and How It Is Actually Won: The Unpublished Criteria That Determine Restoration Work Flow
    5. The Documentation Layer That Makes Every Carrier Conversation Easier

    Crew & Subcontractor Systems (full cluster)

    1. The Restoration Labor Crisis Is Real and the Companies Adapting to It Look Different
    2. Building a Restoration Crew That Stays: Retention at the Field Level
    3. The Restoration Scheduling Problem Is an Operating System Problem
    4. Quality Control as a Continuous Practice, Not an End-of-Job Inspection
    5. The Sub Bench: Building the Reserve Capacity That Lets a Restoration Company Say Yes

    This pillar is being expanded with deep cluster articles on each of the operating layers described above — AI in restoration operations, financial operations discipline, end-in-mind decision frameworks, carrier and TPA strategy, crew and subcontractor systems, and more. Bookmark this page. Every new cluster article will be linked here as it is published.

  • They Printed March Madness on My Guinness. I Haven’t Stopped Thinking About It.

    They Printed March Madness on My Guinness. I Haven’t Stopped Thinking About It.

    I was at Doyle’s last night for my wife’s birthday when the bartender slid a Guinness in front of me. On the foam head: the NCAA March Madness logo, printed in caramel brown like it belonged there. I forgot they did this. And then I couldn’t stop thinking about what it actually meant.

    Let me be clear about what I saw. A neighborhood bar in Tacoma had executed a national brand partnership — NCAA licensing, custom logo printing technology, a real experiential moment — and delivered it to me in a pint glass for maybe twelve bucks. The NCAA didn’t have to run a TV spot to get in front of me. They got in front of me at the exact moment I was already in a good mood, already spending money, already present.

    That’s not marketing. That’s infiltration. And it was brilliant.

    The Technology Behind the Pour

    The machine doing the printing is called a Ripple Maker. It’s a countertop device that uses food-safe ink and an inkjet-style system to print images directly onto foam — coffee, cocktails, beer heads. The company behind it, Ripples, has been running since around 2016. You can print anything: a logo, a photo, a QR code, a personalized message.

    For a bar like Doyle’s, it’s a few hundred dollars a month to run. For a national brand like the NCAA, it’s a scalable ambient media buy — get into bars running March Madness watch parties across the country, put your brand on every beer ordered during the game, and make it feel organic instead of promotional.

    The NCAA didn’t buy an ad. They bought a moment. There’s a meaningful difference between those two things.

    The NCAA didn’t buy an ad. They bought a moment. There’s a meaningful difference. An ad interrupts. A moment becomes part of the memory. I’m writing about this the next day. Nobody writes about a banner ad the next day.

    What Local Businesses Can Take From This

    Bartender using Ripple Maker foam printer technology at a bar
    The Ripple Maker prints directly onto foam — coffee, beer, cocktails. A ~$300/month experiential media channel most brands haven’t touched.

    Here’s where I start thinking about the businesses I work with — restoration contractors, lenders, cold storage operators, B2B service companies. Most of them are buying the same tired channels: Google Ads, Yelp, direct mail. They’re paying to interrupt people.

    What Doyle’s pulled off — even if they didn’t frame it this way — was contextual experiential marketing. The right message, delivered through the right medium, at the right moment, in a way that felt native to the environment. That’s the playbook. The technology is almost incidental.

    The restoration contractor who sponsors the coffee at a claims adjuster’s office every Monday morning is doing the same thing. The cold storage company that puts their logo on the temperature monitoring printout that goes to the produce buyer every week is doing the same thing. You find the moment your customer is already present and mentally open, and you show up there — without asking anything of them.

    Why This Matters for Content Strategy

    I run a content agency. We build articles, landing pages, entity clusters — things designed to get found. And I believe in that work. But what Doyle’s reminded me is that not everything distributable is digital.

    The Guinness moment became a story I’m telling today. That story will probably become a LinkedIn post. That post might become a case study in a pitch deck. The physical moment seeded a digital content chain — and the NCAA got attribution in all of it without ever asking for it.

    Physical moments, done well, generate organic digital content from the people who experience them. Manufacture memorability, not virality.

    I don’t know how much Doyle’s pays for the Ripple Maker. I don’t know what the NCAA paid for the partnership. What I know is that it worked on me — a guy who builds content systems for a living and should theoretically be immune to this stuff. That’s the tell. When the marketing works on the skeptic, it’s really working.


    Happy birthday to my wife, Stef. Best Guinness I’ve had in a while — even if I spent most of it thinking about marketing instead of the moment. She’s used to it.