Ethan Walfish, Head of Onboarding and Scale Services at Haus Analytics, puts it bluntly: "Most support systems are Rube Goldberg machines. You knock one domino down, and then you see what happens down the line."
Most support teams know how that story goes. Usually, the triggers and automations that move each ticket along were never written down. The person who built them left years ago. And when an executive asks how a ticket gets from A to B, the honest answer is often, "Great question, no idea."
Ethan has spent 14 years in B2B support and has been a help desk admin on Zendesk, Help Scout, Salesforce, Intercom, and now Pylon. When he launched the support organization at Haus, he decided to build it differently this time.
He recently sat down with Robert Eng, Pylon’s CPO and co-founder, to walk through exactly how he did it. Below is a look at a few ideas from that conversation. The full session goes deeper into the specific setup choices, prompting approach, and mistakes that made the difference.
When Ethan started building in Pylon in November 2025, the Haus IT team was already using it for internal support, with its own triggers, automations, and reporting. His first rule was simple: don't break anything IT relies on, like the flow that helps an employee get back into a locked laptop.
His mandate was also bigger than the tool itself. Haus runs a services-heavy model, with measurement strategy managers sitting in hundreds of customer Slack channels. Post-sales support work was pulling the onboarding team away from getting new customers up and running.
Ethan made the case to leadership for a dedicated support team, and Pylon became the way one group could hear from, and answer, the entire customer base without anyone living in all those Slack channels.
In the webinar, he explains the structural change that let IT and support share an instance without stepping on each other, and how Slack changes questions as basic as "when is a ticket resolved?"
Every good rebuild starts with a map: where cases come in, what runs on them, which statuses they pass through, what happens when they go to another team, and how they close.
Ethan has drawn these diagrams for years. What changed this time was that he didn't draw this one alone.
He exported his Pylon triggers and automations, spent about 30 minutes describing every intake path out loud with voice-to-text, and handed the whole thing to an AI tool to organize. Then he asked it to find the gaps and ask questions about what he might have missed.
The result was a faster and far more detailed diagram than he had ever built by hand. Robert called it the most practical first step a team can take.
Ethan also shares the habit that keeps this kind of AI work useful instead of producing 20 pages of noise, plus the story of 100 cases that went missing and how an AI review can help surface mistakes like that.
The map made one thing obvious: the triggers were a mess.
Triggers pile up like a rubber band ball over the years. As Ethan put it, “There’s a load-bearing rubber band somewhere at the center that you’re unaware of.”
Ethan's rebuild followed a few principles:
He also made most of the changes in a single day. Low-risk updates like views, columns, and sort order went first. The trigger overhaul happened all at once, carefully planned.
He talks through why he chose that approach, how he now uses AI priority instead of relying on keyword heuristics from past setups, and the math that made a former boss realize the team was spending an entire person’s time just reading tickets.
Ethan once inherited a Salesforce setup so opaque that he did an emergency migration rather than try to fix it. That experience shaped how he thinks about maintenance. A system only one person understands is a liability.
At Haus, he made the setup as close to self-documenting as he could. Every trigger follows a consistent naming scheme, including ones already running in production. He also keeps a live workflow diagram that other admins use to answer their own questions, and refreshes it with AI every few months.
It’s already paying off. A teammate recently made a change that depended on account-level tags and knew to update them without asking.
Could someone else make a safe change to your setup without relying on the person who built it? In the webinar, Ethan walks through what goes into his trigger names and how he keeps the diagram current with almost no effort.
When Robert asked what teams should prioritize first, Ethan didn’t point to a trigger or a feature. He pointed to customer experience, and to the idea that the best support ticket is the one that never gets sent.
“I don’t necessarily want my bot to be deflecting 40% of my volume. I want my bot to be helping customers reduce friction.”
Ethan Walfish, Head of Onboarding and Scale Services at Haus Analytics
By the time a customer reaches out, something has already gone wrong for them. The more useful question is what the bot is answering, and whether the product team could remove the reason for the question entirely.
He gives a concrete example from Haus’s own invite flow in the session, along with how the team uses broadcasts and account memories to keep high-value customers getting a consistent experience.
This post covers the outline. The recording has the rest: the exact routing logic, the prompting approach Ethan uses for every big project, the CSAT mistake you'll want to avoid, and his plans for bringing more Haus teams into Pylon.
If you're inheriting a help desk, launching a support team, or just haven't looked at your triggers in a year, it's worth the time.
Pylon Workforce Management is available now. See it in action with a live demo.
