Why did your AI pilot fail?

Two pages about your company, written by hand. It names why your pilot stalled and the two changes that unstick it. Free. No form, no download gate, nothing to sign up for. You email jason@portillotech.com with what the pilot was and where it stopped, and a PDF comes back attached to a reply.

We can't see your data or your systems from here, so this read stops at the public record. That's the honest limit of a free document, and it's worth knowing before you spend fifteen minutes writing the email. What comes back is a read on the shape of the problem, not an audit of your stack.

Two changes, never three. Three reads as a capability list. Two reads as judgment. Both of them work with anyone: your own team, another shop, or us.

1. Shrink to one workflow that's high volume and light on judgment. One lane, not a copilot for the whole department.
2. Wire it into your own data. Your accounts, your history, your rules. Gartner attributes 85% of AI project failures to data quality and IDC has 65% of teams naming data readiness as the blocker, so plan for this to be most of the work.
3. Write the acceptance test before the build starts. The next section is the whole method.
4. Set the score it has to hit before it touches anything live, and name the person who signs off.
5. Ship it narrow. A narrow thing in production beats a broad thing in demo purgatory, and it gets you a number a board accepts.

The order is the point. Most stalled pilots did step five first and step three never.

For each record, write down the right answer: what the system should have said, ranked, flagged or routed. This is the tedious part and it decides everything. If two people on your team disagree about the right answer for a record, you've found something more useful than an AI pilot.

Then set the number. Not "it should be accurate." Something a person can fail: it puts 8 of the top 10 recoveries in its top 10, and it never misses a case compliance would flag. Pick that threshold before you see any results. Picking it afterward is just describing what you got.

Last, name the one person who signs off. One document, and the conversation moves from trust us to here's the test and here's the score. In a regulated business that document is also what makes the decision defensible when someone asks. Someone will ask.

Shrink first, nearly always. Starting over is an expensive way to make the same two mistakes with a newer model, and the pilot you already ran taught you something about your data that a rebuild throws away. Start over only when the thing you built answers a question nobody in the business actually asks.

If the fix is an LLM wired into your own records, that's the AI consulting side. If the honest answer is that the system you need doesn't exist yet, that's custom software, and it should be scoped as software rather than as a pilot.

No follow-up sequence. If you don't reply, we don't chase you and you don't end up on a list. That's a promise, not a nurture campaign wearing a promise costume.

Keep the autopsy either way. Take it to your own team or to another shop. The paid step, if you want it, is discovery: $2,500, about two weeks. It produces the quantified annual dollar value of your best workflow and the written acceptance test for it. If discovery doesn't surface at least 10x the fee in quantified annual value, you don't pay. The documents are yours to take anywhere afterward.

You can run the math yourself before you spend a dollar. How many people spend how many hours a week on the judgment-light work, by habit or queue order? What does one of those hours cost, loaded? What does the failure mode cost you: the charge-off, the denial, the rework, the missed SLA?

That's also why builds are priced at 10 to 20% of the measured annual value instead of by the hour. If the value isn't there the price doesn't work, and we'd rather say so in a free PDF than eleven weeks into a build. The engineers who map the workflow are the ones who write the code.