Make AI Readiness Someone’s Job

At the end of a series like this, it's tempting to make a big plan. Fix every product, rewrite every answer, contact every site, build every integration. Big plans feel productive, and they can exceed the capacity of a small team. So today's question is smaller, and harder: what will your team actually do in the next thirty days, how will you know each step is done, and how will you undo it if it goes wrong?

This is an educational series from Verity Score for Shopify merchants. Last time, we set up measurements with honest denominators, and kept descriptive observations separate from causal claims. Today, in the last episode of this season, we turn the whole series into an operating routine. Not a transformation. A routine.

We're still following the fictional luggage team. The team, its tasks, its calendar and every decision in this story are invented for the example. No real store, plan or result is involved.

The team has a list. It's long, because every episode added something to it. A product truth card for the convertible backpack, and for the weekender. A reconciliation table that still has an open row about the structured data on the UK page. Five answers with owners, one of them still waiting for the supplier. A correction request that's been sent, with no reply yet. An eligibility matrix with several unknowns. And a measurement sheet with a prompt series that needs to restart.

On top of that list, the developer from episode seven is back. They've followed up with a more detailed proposal, and the founder is tempted again. It's exciting work. It feels like the future.

The team has three people and limited hours. So they lay out two possible months.

Option one: spend most of the month on the integration. The matrix says the relevant rows are still unknown or unconfirmed. So the integration would be built on a capability nobody has confirmed for this store, in these markets.

Option two: spend the month repairing data. Close the open row in the reconciliation table. Finish truth cards for the products that generate the most questions. Update the refund policy to match the actual returns route, then the answers that depend on it. Restart the prompt series from a stable set.

The team chooses option two. Not because the integration is a bad idea forever, but because the matrix says it isn't ready to be decided, and because the repair work helps whatever happens next.

Let's be clear about what the sources say, and what they don't.

For Google's AI features in Search, Google's documentation, which we reviewed on October twenty-second, twenty twenty-six, says that the fundamentals of search still apply, and that there's no special file or special markup required for those features. That's a statement about those Google features specifically. It doesn't describe every assistant or every service. But it does mean that for Google, there's no hidden switch to flip. The ordinary work, accessible and accurate pages, is the work.

For Shopify's Catalog, the documentation describes product data that it shares with eligible channels you've activated: the title, description, options, images, price and availability. It also describes Catalog and web crawling as separate routes, so blocking crawlers doesn't stop Catalog from sharing data with those channels. And it tells you where to check eligibility in your admin. If that data is wrong, it can be wrong in more than one place at once. Repairing it is useful for your own store first, and for any channel that receives it.

What no source we reviewed says is that repairing your data will produce a specific result, in a specific time. That's why this plan doesn't promise sales. It promises completed, verifiable work. If someone tells you that a month of fixes will bring a certain number of orders from AI assistants, ask for their source. In everything we reviewed for this season, there isn't one.

I'll add one assumption, and name it as an assumption. I'm imagining a team that already has some of these pieces in place, because our fictional team does. If your team is starting from nothing, that's not a judgment about you. It just means the right plan is smaller: one product, one answer, one measurement. Adapt the scope to the team and evidence you actually have.

Here's your action for this final episode: build a thirty-day action table, where every row has a proof of completion and a way back.

The thirty days are a working window, not a deadline for results. Nothing in the sources we reviewed establishes that anything will change in an assistant within that time. The window is for your team, so the work has a shape and an end.

The table has six columns. The task. The owner. The proof that it's done. The way back if it goes wrong. The date it's due. And a status: not started, in progress, done, or stopped.

Let's fill it in for our team.

Row one. Close the open structured data row from the reconciliation table. Owner: whoever manages the theme. Proof of completion: the UK page’s structured data and admin agree with the verified commercial availability for each color, checked and dated, with a copy of the code saved. Way back: the previous version of the theme is saved before any change, so it can be restored.

Row two. Finish truth cards for the three products that generate the most support questions. Owner: the product lead. Proof: three cards, each with a job statement, evidence links, unknowns and a date. Way back: none needed. The cards are internal and don't change anything live.

Row three. Update the refund policy to describe the actual returns route for US orders, then align the answers that depend on it. Owner: operations. Proof: the policy, the support template and any other answer about returns say the same thing, with the date checked. Way back: the previous policy text is saved, with the date it was replaced.

Row four. Restart the prompt series. Owner: marketing. Proof: a frozen list of prompts, recorded conditions and a first dated run. Way back: not applicable. It's observation, not change.

Row five. Update the eligibility matrix. Owner: the founder. Proof: each row reviewed against current documentation and the admin, with the date. Way back: not applicable.

Row six. Check the external page from the correction request on the date the team set. Owner: whoever sent the request. Proof: the page captured again, dated, with a note of whether the material description changed. Way back: not applicable. The follow-up check can be completed even if the requested correction remains unresolved. Record the outcome and decide whether a proportionate follow-up is useful; do not close a factual correction as completed if the error remains.

A word about the status called "stopped." It's there on purpose. Sometimes a task turns out to be bigger than expected, or depends on someone outside the team, like the supplier who still hasn't confirmed the care method. Stopping a row, with a note explaining why, is a legitimate outcome. It's much better than a row that stays "in progress" for three months while everyone quietly avoids it.

And then there's a row that isn't on the table: the integration. It's not rejected. It's parked, with a note: revisit when at least one row of the matrix is documented and confirmed.

Two more rules make this a routine rather than a project. First, the team reviews the table once a week, briefly, and updates status, evidence and blockers; changes to the task itself remain explicit. Second, at the end of the thirty days, they review completion evidence separately from business observations. Both matter, but they answer different questions and do not by themselves establish causality. Then they build the next table, starting from what's still open.

Notice what success looks like here. Not a metric going up. A structured data block that matches the admin. A policy that matches the process. A prompt series that can be compared next month. Those are things you can verify, and they don't depend on any service's choices.

The season ends with a practical routine: decide from verified product information, preserve unknowns, and close work with evidence rather than a promised result.

If you take one thing from this season, take the habit of writing down the date, the source and the unknown. Everything else follows from that.

Thank you for listening to this season. Sources and review dates are in the show notes. This episode is read by a synthetic voice.