"It had to be 100% accurate."

The standard, and the order that outran it

Yota Xpedition sells parts for people building out Toyota off-road rigs: the kind of customer who plans a build months ahead and books a shop to do the work. That customer is detail-oriented, and Yota is built to match. Getting the order right, and keeping the customer informed, is the job.

Which is why this one still comes up.

A customer had a wind fairing on order and a professional install booked for February 16th. That appointment had taken a ten-month wait to get, and holding it had cost a $4,000 deposit that wasn’t coming back.

The part wasn’t going to arrive in time. Yota did what a company that cares does: offered to cover the cost of rescheduling, or to cancel that part of the order outright. Neither helped. You can’t move an appointment you’ve waited ten months for and paid a non-refundable deposit to hold. So the customer kept the appointment, and waited on the part.

Nobody at Yota dropped anything. The team was doing this work by hand, every day, as well as it can be done by hand: opening orders, checking the lines, chasing suppliers for dates, writing to customers. The catch is that every one of those steps was a person’s time, and there were far more orders needing them than there were hours to give. So the orders that got worked were the ones the day had room for, and this one didn’t.

For a business that measures itself on customer experience, that is not a small thing. It also wasn’t a one-off:

“Pre Clarissi, in the CS workflow it was super rare for us to keep up with manual backorder reach-outs. We were going through each order individually and emailing customers regarding the backorder status of their items. Getting the ETA for each backordered item was also time-consuming on its own. (about 5-7 minutes per reachout)”

— Furqan Riaz, Customer Service Manager

Read that again. He is not complaining about speed; he is describing a process that could not be finished.

Here is what “super rare” actually meant, in Yota’s own numbers. Reach-outs happened only when the support inbox was quiet enough to allow it, realistically Thursdays and Fridays. On a good week the team got through thirty to forty-five of them. In that same week, the store was taking around five hundred and forty-six orders with a backordered line on them.

So fewer than one order in ten got a heads-up. Everyone else found out the way the customer with the February appointment did: eventually, by asking, or by waiting for something that didn’t come.

The cost of that landed squarely on the support team, in a form that made the problem self-sustaining:

“95% of our backlog was ETA inquiry tickets.”

— Furqan Riaz

That’s the trap, and it’s worth naming because it’s the one most growing stores are in without having put words to it. Not telling people costs more than telling them, but the telling is proactive work you have to find time for, and the not-telling arrives as inbound tickets you have no choice about. The queue crowds out the very work that would shrink the queue. Nobody is failing. The standard just quietly becomes unmeetable at volume.

Yota’s conclusion was not that the team needed to try harder. It was that a promise you keep only when the inbox is quiet isn’t a promise. If they wanted every customer to hear from them before that customer had to ask, something other than a person was going to have to notice.

The problem nobody’s software would solve

The obvious question is why any of this was manual. Yota runs Shopify, and Shopify knows what’s in stock.

The gap is smaller than it sounds and more expensive than it looks. Shopify tracks inventory per product. A customer experiences a shortage per line item, on their specific order. Those are different questions, and only one of them has an answer in the system.

Shopify answers the question on the left automatically, all day long. The question on the right, the one the customer is actually asking, could only be answered by a person, one order at a time.

A person can close that gap: open the order, read the lines against stock, work out which one is short. That’s precisely what Yota’s team was doing. But nothing in the stack would do it for them, or unprompted: not the order confirmation, not the shipping notification, not the admin screen they were looking at. Every answer had to be assembled by hand, one order at a time, which is why the number of customers who got told was capped by the number of hours in the day rather than by the number who needed telling.

Why the obvious fixes weren’t fixes

Yota’s stack is not unusual. Shopify for the store, Gorgias for support, QuickBooks for the books. Each one is good at its job. None of them could answer this.

Shopify knows the inventory but has no per-line-item notion of “this customer is short, tell them.” Its back-in-stock alerts are opt-in for people browsing a product page, not for people who already have an order in hand. Merchants have been asking for the missing piece on Shopify’s own forum for years: no backorder indicator in the cart, in checkout, in confirmation emails, or in the admin.

Shopify Flow, the native automation tool, can’t reach it either. Its product data exposes on-hand stock, not what’s committed, not what’s incoming. The number you’d need to do the arithmetic isn’t available to the tool that would do it.

Gorgias talks to customers, but it starts from customer contact. It can respond brilliantly to someone who writes in. It cannot notice that an order placed nine minutes ago is short two units, because it can’t see inventory at all.

The system that can see the inventory doesn’t talk to customers. The system that talks to customers can’t see the inventory. That’s not a settings problem. No amount of configuration bridges it.

Why they couldn’t just buy an app

This is the question every operator asks next, and it deserves a straight answer.

The app store is full of tools that connect things. What none of them can do is answer a question the underlying platform doesn’t expose the data for. If the number you need, units committed against this specific line right now, isn’t available through the connector, then no amount of wiring produces it. You end up back where you started, except now you’re paying monthly for it.

Which leaves custom development. And that’s its own wall: you have to find someone who’ll build it, brief them properly, wait, pay, and then keep them around when it breaks or the business changes. For a business Yota’s size, that’s usually where the idea dies.

“Our focus was on freeing up our team to execute on higher level tasks while ensuring complete accuracy. This was a big requirement for us, as automating these processes directly impacts a customer’s experience and them getting the actual product they ordered on time. We knew this could be automated but we knew it had to be 100% accurate and it has been!”

— Kyle McLemore, Integrator

That second requirement is the harder one, and it is the whole reason this couldn’t be a weekend project or a rule in an off-the-shelf tool. The standard that made the problem worth solving is the same standard the solution had to clear: a message that reaches the wrong customer, or names the wrong item, is worse than no message at all. It takes a company known for getting details right and makes it the thing sending confident nonsense. The team’s own review before launch is part of why it held:

“Speed and accuracy. I was able to scrutinize and work through all the issues before launch with Matt, which ensured 100 percent accuracy from day one.”

— Furqan Riaz

What we built

The first version was a standalone application. It worked, and it was one more thing to own, with its own deploy, its own maintenance, and no path to anything else Yota might need later.

We moved it onto the Clarissi platform. Same behavior, now with retry handling, deduplication, a full execution history, and message templates Yota’s team edits themselves without calling anyone.

Now, on every order that arrives:

• Every line item is checked against real inventory, not the order’s status
• A partial shortfall is distinguished from a complete one, because those are different conversations with a customer
• Yota’s own rules apply: excluded suppliers, excluded product categories, stock thresholds, fulfillment location
• Test and zero-value orders are left alone
• If something is genuinely short, a message goes out through Gorgias with the item, the situation, and Yota’s own language already in it

The customer hears from Yota before they have to ask.

1,493 orders carrying $510,323 in order value have been handled this way. Every one is an order where the system confirmed a shortfall and confirmed the customer was contacted.

Average order: $342, across every order since the skill went live on May 8th.

That is 1,493 customers who got the message the customer with the February appointment didn’t.

These come from execution records, not estimates. And a deliberate limit on the claim: this is order value addressed, not revenue saved. We can show the customer was reached and what their order was worth. We can’t show what they’d have done otherwise. That would require knowing what someone would have chosen, and no system observes that. The honest number is the one worth publishing.

“We now have a much simplified process for backorder reach-outs. The agent only needs to split the order once the customer responds with their choice, which allows us to be more effective in the inbox for tickets that require attention.”

— Furqan Riaz

That’s the shape of the change worth noticing. The job didn’t disappear. It narrowed to the one step that actually needs a person. Nobody is hunting for which orders are short, or chasing ETAs, or writing the message. What’s left is handling a customer who has replied with a decision, which is the part where judgment is worth paying for.

The steps didn’t change. Every one of them was already being done, by a person, on whichever orders the day had room for. That was the ceiling: thirty to forty-five a week against roughly 546 that needed one.

The clearest measure of the change is the cadence. Reach-outs used to be squeezed into Thursdays and Fridays, whenever the inbox went quiet enough to allow it: thirty to forty-five in a good week. Now:

“We do not have to think about volume at all and we get through about 20+ reach-outs every single day, including weekends.”

— Furqan Riaz

Twenty a day, seven days a week, against thirty to forty-five on two days when the queue happened to permit it. The same process did not get faster. Work that had to be scheduled became work that simply happens.

And it broke the loop that was feeding the queue. Those ETA inquiries, 95% of the support backlog, were customers asking a question that a message sent on day one would have answered. Yota’s own first-response time moved on the back of that, not because anyone was typing faster, but because the tickets stopped arriving.

“The shift was only possible due to us being proactive with our reachouts and our workflow for backorder inquiries being cut off significantly.”

— Furqan Riaz

Their target was eight hours. They missed it every month through May, and have met it every month since. February through April averaged eighteen hours; June and July averaged under six.

Two honest caveats on that chart. January’s fifty-two hours is peak season, not a mystery: Black Friday, Cyber Monday and the Christmas and New Year sales all arrive in the same queue, and that month set Yota’s record for ticket volume. It’s shown because leaving it out would be worse, and kept out of the averages because measuring their busiest month against ordinary ones distorts the comparison in both directions. And the reach-outs aren’t the only thing that changed: Yota’s in-stock rate improved over the same period, which cut backorder volume on its own. Fewer backorders means fewer ETA tickets, whatever else is running. What the reach-outs did was stop the remaining ones from becoming tickets in the first place.

The downstream effect is the one the customer with the February appointment never got:

“Customers appreciate the reach-outs a lot since they are informed almost instantly and can make their choice, in many cases scheduling professional install appointments, based on the ETAs we provide. We haven’t gotten feedback in those exact words, but I have seen a shift in customer retention since we are proactively letting them know the status rather than them having to reach out and ask us first, which builds trust. Overall customers seem more satisfied since we can now effectively do reach-outs every single time.”

— Furqan Riaz

An ETA that arrives the day the order is placed is a different object from the same ETA a month later. Early, it’s a decision: book the shop, or don’t book it yet. Late, it’s only an explanation.

The order that has to leave the building

The backorder work paid for itself, and more usefully, it meant Yota’s systems were already connected. The next thing didn’t start from zero.

Part of Yota’s catalog doesn’t ship from Yota. It ships from the supplier, direct to the customer. Which means every one of those orders needs a second order placed by a person: reading the Shopify order, writing an email to the vendor with the right line items, and then remembering they did it.

That last part is where it goes wrong. Miss one and a customer waits for something nobody ordered. Send it twice and you’ve bought the parts twice.

Now, when an order is paid, the system checks whether any of it ships from a supplier. If it does, it places the order, an email to the vendor with exactly the right lines, and tags the Shopify order so everyone can see it’s been handled.

Two things stop it doubling up: it records that the order was placed before it sends anything, and it checks that record plus the tag before it ever sends again. Something has to be able to fail without a customer paying for it.

Then the other half of the same loop: the supplier ships, and sends a confirmation email with the tracking number. Someone was reading those and typing tracking numbers into Shopify by hand, closing manually the loop the system had automatically opened.

That supplier offers no API, no EDI, and no export, which is ordinary for smaller vendors. The integration you’d want was never built, and never will be. So the email itself becomes the input: it arrives, it’s verified as genuinely from the supplier, the tracking number is read out of it, and it’s written against the right portion of the order, because an order can be part supplier-shipped and part from Yota’s own shelves, and only one of those halves is now in transit.

Yota described this gap themselves, which is how most of this work starts.

(The return leg is built and in testing as of August 2026, not yet live. The outbound half has been running for months.)

“Matt was able to meet with our team, get clarity on what outcome we wanted and why, and then worked to build and test our processes. Over time he’s developed a good understanding of our organization and knows how our systems work, where he can pull from and how to keep things running well. If we hired a freelancer for these they would not have the developed context that he does and would potentially miss key systems or integrations to help us get the outcome we want, with the consistency we want.”

— Kyle McLemore, Integrator

That’s the argument for this model stated better than we’d state it. The first build is the expensive one because it’s the one where the context gets acquired. Everything after is cheaper for exactly the reason Kyle names: the systems are already connected and someone already knows how they fit together.

The question five systems couldn’t answer

Then Yota asked for a dashboard. It turned out to be the most interesting request of the engagement.

Are we making money this month? is a simple question with a scattered answer. QuickBooks has the revenue and the cost of goods. Shopify has the orders and what the average one is worth. Google Ads and Meta Ads each hold their own spend. Klaviyo has what the email is doing. Five systems, none of which talks to the others.

So answering it meant opening all five and reconciling them by hand. Which meant, in practice, answering it rarely.

Yota’s first move was the one most people would make now:

“We originally were manually calculating a lot of our numbers. Then we moved to a dashboard created by Claude. The dashboard itself was easy to pull together. However, it wasn’t consistent every week, and it started to take more time to manage AI and get accurate numbers than was worth it.”

— Kyle McLemore, Integrator

Sit with that one, because it’s the objection to everything in this case study, and Yota tested it before we got there. They didn’t wonder whether AI could build the dashboard. They built it. It worked.

Then it stopped being worth the effort.

The failure wasn’t capability. It was consistency. A dashboard a chat tool assembles is generated fresh every time, so it can come back subtly different every time: a metric defined one way this week and another way last, a number that doesn’t tie to the one before it. For a question you ask once, that’s fine. For a number you make decisions against every week, it isn’t. The cost shows up as a person checking the AI’s work, and Kyle is describing exactly that: the tool got faster and the human got slower.

What they have now is one live executive view. Year-to-date revenue and margin from QuickBooks. Monthly revenue against cost of goods and ad spend. Contribution margin trend. Unit economics: return on ad spend, cost to acquire a customer, average order value. Revenue broken out by account.

Same five systems. Nobody opening any of them.

It also tells you where not to trust it. Where the ad history doesn’t cover a month, the row says so. Where a channel isn’t connected yet and a ratio is flattering as a result, it says that too. A number that admits when it’s incomplete is worth more than a confident wrong one, and for a company whose whole standard is getting details right, that mattered more than the dashboard looking finished.

The real view, with every figure blurred. Note the labels down the left of the monthly table: NO AD DATA, PARTIAL AD DATA, MTD. Those are the dashboard telling you which rows you can trust and which you can’t.

“Matt has been able to build this dashboard for us and it has been very accurate. We are in phase 1.0, but now that we have accurate numbers we will be continuing to refine our numbers.”

— Kyle McLemore, Integrator

“Now that we have accurate numbers” is the phrase doing the work there. Refining is something you can only do on top of a base that holds still. That’s what the first attempt couldn’t give them, and it’s the whole difference between a dashboard that impresses once and one you can run a business on.

And it costs almost nothing to keep running. Ask a chat tool this question and it pulls your raw records into context every single time, re-reading them and re-charging for them on every question. This one is authored once against a model of the business and then refreshes without paying to re-read anything. The cost tracks the question, not the size of the data behind it. For a view someone opens every week, that gap only widens.

Where it stands

Three things run every day now: backorder notifications, supplier order placement, and the executive dashboard. A fourth is in testing.

None of them were on a roadmap. Each one started with Yota describing something their team was still doing by hand.