Ask an AI vendor for its time to production, and skip the demo

We read every customer story Wonderful has published, and each one starts the same way: with the time it took to go live. A first voice agent at Bank Hapoalim in 72 hours. A collections agent at the Colombian bank Banco Caja Social in production in 19 days. An internal IT agent at the Turkish fuel company Petrol Ofisi live three weeks after signing. A Greek postal tracking agent at ELTA in five weeks. Three WhatsApp agents at Mercado Libre's vehicle marketplace in ten weeks.

These are the company's own accounts, with the customer's executive quoted on Wonderful's site, so treat them as claims. What interested us was the form of the claim. Almost every AI vendor starts with a demo. Wonderful starts with the date a contract was signed and the date real users were served, and the gap between them. That is a better proof, and a harder one to fake, and it gives a buyer three questions to ask any vendor instead of watching a demo.

1. When was the contract signed, and when did the first real user get served?

A demo measures the model. The vendor picked the example, prepared the data, and practised every step. Every vendor you are considering has access to the same models from the same providers at the same price, so the demo tells you what you could have built yourself.

The time to production measures the vendor. Everything between the signature and the first real user is work inside your company: connecting to billing and ticketing, respecting permissions, passing the security review, deciding what the system may not do, and getting the people whose routine changes to accept it. Wonderful's own careers page describes its deployment strategists as people who "own deployment and are measured on customer P&L outcomes", which is a company telling you which number its staff are paid on.

The question, then, is two dates. When was the contract signed, and when did the first real customer or employee get served in normal operation? A vendor that has done it will give you both for a named customer. If the answer is a demo, or a pilot with no end date, the number does not exist yet. That is useful to know before the price conversation.

The gap also tells you where the time went, if you ask for the breakdown. Say a vendor gives you a signature on 3 March and a first served customer on 21 April, seven weeks. Ask how many of those weeks were the security review, how many were waiting for access to a system, and how many were the vendor's own build. A seven-week gap where five weeks were the customer's own procurement is a different vendor from one where five weeks were rework, and the honest ones will tell you which, because the breakdown is also their argument for a shorter time next time.

2. What did "production" mean, exactly?

The second question checks the answer to the first one, because "in production" can mean almost anything. A system serving 2 percent of traffic behind a person who checks every answer is in production in one sense. So is a system serving all of it.

Ask for the share. What percentage of the real volume went through the system in its first month, on which channel, and what share was still handed to a person? Wonderful's case studies give a resolution rate next to each time, 77 percent of billing issues at Telefónica's Colombian operation and 86 percent of tracking calls at ELTA, again by the company's own account, and whatever you think of the numbers, the pairing is right. A time without a share of traffic is only a launch date, and a launch date on its own means little, because the day a system first answers one call is also the day most pilots start, and many then stay at 2 percent for months.

The failure this catches is the permanent pilot. A pilot that never reaches the full agreed traffic usually means the integration or the trust was never finished, and it continues because a running pilot looks like a customer in the vendor's sales slides. Wonderful's deployment page states its aim as getting "the right use case into production, fast" so that "value is real before you scale," which is the right order. Make your vendor commit to it with a date: by this day the system either serves the agreed share or it is rolled back. Three contract terms matter most. A share of real traffic the system must carry by a named date. A definition of handled, meaning the case closed without a person touching it, so that a system which routes everything to a human cannot count as resolving anything. And a rollback trigger, the error rate or complaint count at which the old process comes back automatically, agreed before launch when nobody is defending a result. We explained how to write those into a contract in How to structure a pilot before a full engagement.

3. Who built the second workflow?

The third question is about what happens after the first system goes live, and its answer shows which of two outcomes you will get.

Wonderful's Series B announcement in March 2026 claimed that over 70 percent of its customers expand to additional workflows within three months. That can mean two different things. In one, the customer's own people built the second thing on the platform they now own. In the other, the vendor's people were needed again, and the expansion figure is a measure of dependence. An Israeli AI community figure, Uri Eliabayev, described the second reading to CTech in September 2026: the company realised early that "once they got their foot in the door of an organization, it needed more and more assistance and guidance".

Wonderful's own reply to that criticism is its handover. Its homepage describes local teams who "build it with you, then hand it over and move to the next use case," and its Bank Hapoalim story describes a bank data engineer with no agent experience building and releasing the second agent in three weeks by reusing 15 tools the vendor's team had built, by Wonderful's account. If that is true, it is the strongest claim on the site, stronger than any time figure, because it means the skill to build the system passed to the customer's own team.

So ask the vendor who built the second workflow at its reference customer. If the answer is the customer's engineer, ask to speak to that engineer, and keep the call short: how long from ticket to production, which checks had to pass before it was released, who wrote those checks, and what the engineer did the first time one failed. An engineer who owns the system answers all four from memory. An engineer who was handed a system answers the first and then names the vendor. If the answer is the vendor's team again, the time you were shown measures the first deployment only, and the second one will again depend on the vendor's paid time.

What this means for us

We are a young company and we will not pretend otherwise. Our pages label every timeline as the one we scope to, because a scoped timeline and a measured one are different numbers, and we will not print the second until we have it. What we can show today is the specification a build starts from, the eval suite a change must pass before it is released, and the date we commit to. When we have our first measured time we will publish both dates, and the share of traffic, and who built the second workflow.

Our thanks to the teams at Wonderful who chose to publish dates instead of demos, whatever the figures turn out to be when someone checks them. The habit is the right one. A demo shows what the model can do. The time to production shows what the vendor can do.

Sources

• Wonderful, Bank Hapoalim case study: the 72-hour figure and the bank engineer's second agent. Company claims.
• Wonderful, Banco Caja Social case study: the 19-day figure. Company claim.
• Wonderful, ELTA case study: the five-week figure and the 86 percent resolution rate. Company claims.
• Wonderful, Petrol Ofisi case study: the three-week figure. Company claim.
• Wonderful, careers page: the deployment strategist role description.
• PR Newswire, 12 March 2026: the Series B announcement with the 70 percent expansion claim. Company press release.
• CTech, Sophie Shulman, 6 September 2026: the Uri Eliabayev quote on customers needing more assistance once the vendor is inside.