The execution gap

Somewhere in your store right now, a product page is not doing its job. A variant will not add to the basket. A landing page promises a price the product no longer carries. A category has quietly stopped ranking. An alert fires, or a shopper complains, or nobody notices for a week.

Then the real cost begins. The alert becomes a ticket. The ticket finds a person. The person investigates, works out a change, asks somebody to approve it, deploys it and checks the page again. Your business carries the problem for every minute of that journey, and the bill is set by how many shoppers meet it before it is gone.

I call the distance between a problem being detected and a verified change landing in the store the execution gap. It is investigation, decision, coordination, approval, implementation and verification, usually spread across three tools and three people, with the merchant holding the whole thing together by hand.

Once you start looking for it, you see it everywhere. The catalogue error that three people can each see and none of them owns. The checkout journey that fails on one device, reported twice, fixed never. The ad campaign still sending traffic to a page that changed on Tuesday. None of these is hard to understand. All of them are hard to carry through. That is where revenue leaks: not in the finding, in the carrying.

The gap is getting wider, not narrower

AI has made it cheap to find problems and cheap to draft fixes. That sounds like the end of the gap. It is the opposite. A tool can now generate recommendations faster than any team can review, approve and apply them, so the bottleneck moves from spotting the problem to finishing the work. A dashboard with forty findings and no owner is not insight. It is a to-do list nobody asked for.

Ecommerce needs a clear owner for the whole distance. Vortex IQ is the execution layer for ecommerce. It closes the gap between a signal appearing and a verified change landing in the store, across the platform and the connectors around it, with a person approving every change. Show. Approve. Apply and verify. Roll back.

Merchants experience that layer as the AI workforce for ecommerce: six specialist crews, each responsible for one job you already pay someone to do. Pulse for Store Health, CodeCraft for Store Development and Bridge for Staging and Migration stop revenue leaks. Beacon for SEO and AI Visibility, Muse for Store Experience and Compass for Ads Performance accelerate growth. Each crew finds the problem, explains it with evidence, prepares the fix, and carries it through approval to a verified result.

Three numbers, not a promise

If that is the job, then the job should be measured, and I should be measured against it. So we hold ourselves to three numbers on every corrective piece of work, and they are visible to every merchant in their own workspace.

Time to Fix, TTF. The elapsed time from the first detection of an issue to verified confirmation that the correction is live and working. Not to a ticket. Not to a deploy. To evidence. Approval time is inside the number, because you experience it, and it is also broken out, so you can see where the minutes went.

Fix Acceptance Rate, FAR. The share of first proposals a reviewer approves without editing or sending back. A fix that keeps needing rewrites has handed the work back to you. FAR is how I know whether the workforce understood the store, or merely produced something plausible.

Fix Reuse Rate, FRR. The share of verified fixes that materially used a solution already proven to work. This is the number that says whether the workforce learns. Every store is different, and no merchant's data ever crosses to another, but the method for guarding a template change or repairing a broken redirect chain should not be reinvented on every job.

I chose these three because each one can be checked. Every fix leaves a record: when it was detected, what was proposed, who approved it, what ran, whether it was reused, and what proved it worked. The numbers are read off that record. There is no other source.

What one job looks like

On a Tuesday morning, Pulse, the Store Health crew, detected that one size on a best-selling product page returned an error when added to the basket. A theme update the night before had broken the variant selector for that size only. CodeCraft, the Store Development crew, prepared the fix.

• Detected: 08:42
• Fix proposed, with the failing request and the template change: 09:03
• Approved by the merchant's ecommerce manager, unchanged: 10:37
• Deployed, basket journey re-run and passed: 10:49
• Time to Fix: 2 hours 7 minutes

Twenty-one minutes of preparation, ninety-four minutes waiting for a person, twelve minutes to apply and verify. The waiting is the part I want to shrink, and the way to shrink it is not to remove the person. It is to give them a clearer proposal, better evidence and the right name on the request.

That proposal was approved on first sight, so it counts towards FAR. Across that merchant's month, 46 first proposals reached a decision: 38 approved unchanged, six revised, two rejected. FAR was 83 per cent. The eight that were not accepted taught us more than the 38 that were.

The fix itself reused a template guard first validated on a different store in June. It counted towards FRR, which stood at 57 per cent for the month, and the merchant's record shows exactly which earlier solution was reused and how it was checked in their store.

Read them together

One number on its own can flatter. TTF falling while FAR falls too means proposals are reaching people faster and worse. FAR rising while TTF stays high means the proposals are good and something else is slow, usually the approval queue. FRR rising while cost and time do not move means the reuse is too shallow to matter.

Progress is all three moving the right way on comparable work, with the business weight of that work kept in view. Fixing two hundred low-priority fields is not the same as fixing a checkout.

Ask every provider. Ask us.

You don't need to buy anything to use these numbers. Take one real issue in your store and ask whoever handles it, an agency, an internal team or an AI workforce, four questions.

When was it first detected, and what evidence proved it was fixed? How many first proposals needed revision, and how much of the work did your reviewer end up doing? What was reused from earlier work, and did it reduce the effort? And show me the unfinished and the failed work, not only the successes.

A provider who can answer those from a record, rather than from memory, is one you can hold to account. That's the standard I want Vortex IQ judged against, for every merchant, every month.

The full definitions, including what counts and what does not, are published in How Vortex IQ measures execution.

Frequently asked questions

What is the execution gap in ecommerce?

The execution gap is the time and effort between a problem being detected in an online store and a verified fix landing in the live store. It covers investigation, decision, approval, implementation and verification. Vortex IQ uses the term for the work that sits between a finding and a result, which most tools leave to the merchant to carry by hand.

What is Time to Fix (TTF)?

Time to Fix is the elapsed time from the first recorded detection of an issue to verification that the correction is live and working in the store. It includes the time spent waiting for a person to approve the change. Vortex IQ reports that waiting time separately, so a merchant can see where the minutes went.

Is Time to Fix the same as mean time to resolution?

They are related but not the same. Mean time to resolution usually stops when a ticket is closed or a change is deployed. Time to Fix stops only when evidence shows the correction working in the live store. It is reported as a median and a 90th percentile rather than a mean, so one difficult job cannot hide inside an average.

What is Fix Acceptance Rate (FAR)?

Fix Acceptance Rate is the percentage of first fix proposals that a reviewer approves without editing or sending back. It measures whether the AI workforce for ecommerce understood the store well enough to hand over work that is ready, rather than work that is merely plausible. Every revision or rejection is recorded with a reason.

What is Fix Reuse Rate (FRR), and does it mean my data is shared?

Fix Reuse Rate is the percentage of verified fixes that materially used a solution already validated on an earlier job. Methods travel between stores. Merchant data does not. Each store keeps its own context, permissions and checks, and no merchant's information is moved to another merchant's store.

How can I see these numbers for my own store?

Every Vortex IQ merchant sees Time to Fix, Fix Acceptance Rate and Fix Reuse Rate in their own workspace, per crew and in total, with the record behind each figure one step away. Any provider can be asked the same questions: when was it detected, what proved it fixed, how many proposals needed revision, and what was reused.