Thirty days of hypercare: how we sit with the business after go-live
Going live is where the real work starts. For AutoBid’s first month, AISE, the Specials team and the Product Portal team tested together every day, shipped more than 40 fixes through DEV, TEST and PROD, and told the business about each one in plain language. The engine stayed up the whole time.
Go-live is the start
AutoBid went live on Saturday, August 22 at noon. The cutover had been planned and rehearsed, and the first weekend went cleanly: every request evaluated, none lost, nobody stepping in to rescue anything. But the team treated go-live as the start of the job. Real dealer traffic behaves differently from any test set, and the first weeks are when a new system earns or loses the trust of the people who depend on it.
“A go-live with nothing to report is the hardest kind to pull off.”
— Michael Pietrangelo, go-live day note to the team
Who was in the room
Hypercare was a daily working partnership. Larry Kallio, the business owner, set the direction. Lisa Grimmer, on the Product Portal side of the integration, was central to hypercare. She put real requests through, spotted what looked wrong, and made the Portal-side changes that kept the two systems in step and requests flowing. Nate Zylstra, the technical analyst between AISE and the Specials business, turned what the team was seeing into prioritized work. The Specials quoters made the ruling on every questionable evaluation, because they are the ground truth. AISE turned each flagged evaluation into a ticket, a fix, a regression test, and a promotion through all three environments, often on the same day.
What we fixed
The first six days brought five production pushes. Some fixes were about speed: the Portal applies its own time limits, so the team took identifier lookups off the critical path. Then it returned the Portal’s acknowledgment before the Claude session was even created, which cut the wait from 7.8 seconds to about one. A ten-line quote that had been overrunning the Portal’s 55-second window came in at 30.5. Some were about money: a per-cutout upcharge applied once instead of per unit, an incomplete total that didn’t say so (it now carries an asterisk), and a declined request that still showed a price (it no longer does). Some were about trust: an internal formatting instruction once leaked into a quote a dealer could see, and a discontinuation notice for three unrelated product lines was once applied to a fourth. Each was traced to its cause and fixed at the source.
Some fixes made the engine more capable. It learned to read pricing tables stored in attachments rather than on the page, which cleared real asterisked quotes on the first try. It started recognizing when a requested change is actually a standard or Vary Easy product MillerKnoll already sells. And it moved to the Portal’s own decision vocabulary, so the quoters and the engine finally use the same words.
Telling the business, in their language
Every release went out with a short changelog written for the people using the Portal, not for engineers. It covered what changed, what they would notice, and what to watch for, such as saved filters that would need the new decision labels. Changes that only affected cost or reliability said so plainly, so nobody wondered whether their quotes had shifted. Each changelog closed with the same line, and it was true every time: please keep flagging evaluations that look wrong, because every fix started as one.
“Please keep flagging evaluations that look wrong — every fix above started as one.”
— AutoBid changelog, Engine v2.3
Uptime, on purpose
Shipping forty fixes in a month without breaking a live system took discipline. Every change went DEV → TEST → PROD with a regression suite gated on the decision and the dollars, not on whether a response came back. Flow promotions were verified by hashing their definitions, because a matching version number proves nothing. The alert monitor was retuned to ignore the team’s own test traffic, so a page always meant something real. When one early fix made things worse, it was caught by exactly that process and rolled forward within a day.
What the business got
By day 30 the engine agreed with the quoters’ actual decision 91.7% of the time, above the pre-launch estimate, and quote response time was down from about 72 hours to 26.1. Just as useful, the business got a precise map of its own knowledge gaps. Most escalations were “no governing article” rather than a hard engineering question, and the top recurring ones went back to the Specials team as article drafts. That is the pattern AISE follows on every project: work alongside the people who own the process, test with them every day, and fix what they find.