Blog ·

An honest postmortem of an AI feature with no war stories

Most AI postmortems are war stories. This one isn't. Notes on a small Spanish-translation tech that ran for months without drama, and the design decisions that kept it that way.

Most AI postmortems are war stories. This one isn't.

While I was at my prior MSP, I built a small AI feature inside the Syncro instance. It watched inbound tickets, detected language, and for anything that wasn't English, posted an English translation as a comment on the ticket. Then it stayed out of the way. It ran for months without notable drama.

That's the whole story. But the design choices behind it are worth the writeup. Most successful small AI features look like this, and most write-ups of AI features don't.

The 10% problem

About 1 in 10 tickets came in Spanish. The team had one Spanish-speaking tech, which meant either she handled all of them (and got buried), or the rest of the team copy-pasted ticket text into Google Translate and worked from the rough rendering. Neither scaled, and the buried-tech version was actively unfair to her.

The build, in one sentence

An agent watching the inbound ticket feed via the Syncro API; for any ticket whose body wasn't English, a translation step rendered it into English and posted the result as a comment. English tickets were ignored entirely. Done.

The design choices worth noting

The interesting parts of any small feature are the decisions you made not to do something. Four of them mattered here.

Comment, not replacement. The translation went into a new comment. The original ticket body stayed intact in the customer's words. Audit trail preserved. If the translation was ever wrong, the original was a click away. If we'd overwritten the original, we'd have created a one-way operation with no recovery path.

Language-detect first, not "always translate." The agent looked at the body before doing anything. English tickets (the bulk of the queue) were skipped without spending an API call. This made the feature both cheaper to run and impossible to misfire on an English ticket that happened to contain the word "hola."

Non-optional. No opt-in flag, no per-tech toggle, no UI for "enable translation on this ticket." The feature just ran. The cost of building an opt-in mechanism would have been higher than the value of the opt-out option, and the half-life of any "enable this feature" flag is about a week before it's forgotten.

Don't touch the outbound replies. When the team replied to a translated ticket, they replied in English. Translating their replies back into Spanish for the customer would have been a natural extension, and we didn't build it. Half the value with a quarter of the complexity, and none of the risk of an AI directly speaking to customers in a language no one on the team could verify in real time. The team handled outbound the same way they always had.

What this teaches about AI feature scope

The smallest version that captures most of the value usually wins. Most "ambitious" AI features fail because they try to do the whole job. This one did one tightly-scoped thing (inbound translation as a comment) and stopped.

Reception was good. The previously-buried Spanish-speaking tech got her queue back. The rest of the team stopped reaching for Google Translate. No one complained. No one had to be trained on a new tool. The feature became invisible, which is usually what "successful AI" looks like in operations.

The postmortem in one line

If you have a feature in your queue where the AI postmortem is "it just worked and no one noticed," you probably scoped it correctly. The AI postmortems with drama are the ones where the scope was too ambitious and the review loop too thin.


What's the most boring AI feature you've shipped that just worked?

← All posts