Why is time to production a better proof than a demo?

A demo shows what the model can do on a stage the vendor built, and every vendor has access to the same models. The gap between the date a contract was signed and the date real customers were served measures everything the vendor had to do inside your systems, which is the part you are actually paying for.

What two dates should I ask an AI vendor for?

The date the contract was signed and the date the first real user, customer or employee, was served by the system in normal operation. If the vendor can give both dates for a named customer, the gap is your number; if it can only offer a demo or a pilot, the number does not exist yet.

What counts as production when a vendor claims it?

Real traffic, at a stated share, with the old process no longer running alongside for the cases the system handles. Ask what percentage of the real volume went through the system in its first month and what share was still handed to a person, because a pilot serving 2 percent of traffic behind a human safety net is a different thing from production.

What does it mean when a pilot never reaches full traffic?

It usually means the integration or the trust was never finished, and the vendor kept the pilot alive because a running pilot looks like a customer. Set a date at contract time by which the system either serves the full agreed share of traffic or is rolled back, so the pilot cannot become the permanent state.

Is a fast expansion figure a good sign or a warning?

Both, and you have to ask which. Wonderful states that over 70 percent of its customers expand to more workflows within three months, and an Israeli AI community figure told CTech the company realised early that once inside an organisation the customer needed more and more help, so ask whether the expansion was your people building on the platform or the vendor's people being needed again.

What if a vendor has no time-to-production figure yet?

Then ask for the commitment and how it will be checked. A vendor without history can still show you the specification it works from, the checks a change must pass before it ships, and the date it commits to, and a vendor that labels its timelines as scoped, because nothing has been measured yet, is being straight with you.

Are Wonderful's time-to-production figures independently verified?

No. They come from Wonderful's own case studies, with customer executives quoted on Wonderful's site, so they are the company's account of its own work. The point of this piece is the shape of the proof, two dates and a gap, which any vendor can be asked for and any buyer can check against their own contract.

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

Q: Who should build the second workflow after the first one is live?

Your own people, with the vendor available for questions. Wonderful's account of its Bank Hapoalim work describes a bank engineer with no agent experience shipping the second agent in three weeks by reusing tools the vendor's team had built, and whether your team can do the same is the real test of a handover.

We read every customer story Wonderful has published, and each one opens the same way: with a clock. 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 hold them as claims. What caught our attention was the shape of the claim. Almost every AI vendor leads with a demo. Wonderful leads 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 rehearsed the path. Every vendor in the room 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 clock measures the vendor. Everything between the signature and the first real user is work inside your building: 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 clock 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 clock next time.

2. What did "production" mean, exactly?

The second question keeps the first one honest, 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 clock, 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 clock without a share of traffic is 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 begin their long stay at 2 percent.

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 survives because a running pilot looks like a customer on the vendor's slide. 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. Hold your vendor to it with a date: by this day the system either serves the agreed share or it is rolled back. Three terms do most of the work. 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 laid out how to write those into a contract in How to structure a pilot before a full engagement.

3. Who shipped the second workflow?

The third question is about what happens after the clock stops, and it is where the two possible futures separate.

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 answer to that charge 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 shipping 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 clock, because it means the capability moved.

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 shipped, 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 clock you were shown measures the first deployment only, and the second one will run on the same meter.

Where that leaves 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 ships, and the date we commit to. When the first clock exists we will publish both dates, and the share of traffic, and who shipped 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 under audit. The habit is the right one. A demo shows what the model can do. A clock 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.