Anyone running Lindy at scale for customer-facing automation

Hi Jason. We've been on a similar path, running a mix of internal and customer-facing Lindys for about a year now.

> How often do you need to step in?
We found the initial tuning period is crucial. For the first few weeks, we monitored everything daily. After that, we step in maybe once a week, mostly for edge cases our logic didn't catch. The biggest "gotcha" isn't the automation failing, but the automation being *too* literal. A customer might ask something in our FAQ flow that's technically covered, but their phrasing indicates high frustration. We built a rule to escalate any interaction where sentiment markers pop up more than twice.

We have a part-time "Automation Lead" who oversees the core logic and integrations, but each department (support, success, sales) owns and tweaks their specific Lindy workflows. That keeps things grounded in actual use cases. Our most complex setup is a post-trial onboarding sequence that pulls data from three systems (our CRM, the product backend, and Intercom) to personalize the next-step recommendations. It works well, but I'll be honest, the integration testing before we launched was a bear.

What's your current stack look like for these customer touchpoints? That integration layer really dictates how smooth this shift will be.

Reliability's the easy part. The hard part is threat modeling and access control when you connect these automations to customer data and systems.

Complexity? We have a Lindy that handles PCI-DSS scoped data requests. It's a state machine that validates the request, checks identity via our IDP, pulls logs from three systems, redacts in a sandbox, and delivers via a secure channel. It required custom logic at almost every step. The cost wasn't in building the happy path, it was in engineering all the failure modes and audit trails.

You need a dedicated owner. Not just a lead. Someone accountable for the security review of every new integration and logic change. Otherwise you'll end up with a customer-facing automation accidentally exposing internal API keys or ticket numbers.

Jason, I've been running performance and reliability testing on Lindy workflows for enterprise clients for the past 18 months. Let me address your points with some data from our benchmarks.

On reliability, the primary metric we track is "human intervention rate per 1000 executions." For mature customer-facing automations, a well-tuned system should stay below 2%. The critical "gotcha" we observe isn't just sentiment, but intent misclassification under load. When API latency from integrated services (like your CRM) exceeds 800ms, Lindy's decision engine can time out and default to a fallback path, often misrouting a complex ticket. You need to implement circuit breakers and track this as a key SLI.

Our most sophisticated workflow handles dynamic pricing inquiries for a SaaS platform. It pulls real-time usage data, compares it against historical contract benchmarks, runs a forecast simulation, and generates a draft amendment. The complexity isn't in the steps, but in the validation layer that audits every data input against a known-good baseline to prevent hallucinations from stale cache data.

You absolutely need a dedicated owner, but I'd expand on user974's point. That role must also be responsible for continuous load testing. The performance profile of a workflow changes dramatically with scale. A sequence that works for 10 concurrent users will fail differently for 100 due to contention in shared resources like database connections from Lindy's backend. We schedule weekly canary tests against a cloned production environment to catch these degradation patterns before they impact customers.