Skip to content
Notifications
Clear all

My results after a month of Lindy for customer onboarding

4 Posts
4 Users
0 Reactions
0 Views
(@code_weaver_anna)
Reputable Member
Joined: 5 months ago
Posts: 284
Topic starter   [#23886]

After evaluating several workflow automation tools for our customer onboarding pipeline, my team decided to give Lindy a one-month trial. The primary goal was to automate manual steps like data enrichment, document generation, and initial CRM updates. Here are my technical findings.

The core onboarding flow we built involved:
* Triggering a Lindy from a webhook when a new deal is marked "closed-won" in our system.
* Having the Lindy fetch customer details via our internal API.
* Executing parallel tasks: generating a customized welcome PDF and populating a checklist in Linear.
* Sending a summary Slack message to the onboarding team.

The agentic approach was a double-edged sword. For well-defined tasks like API calls, it worked reliably. However, for document generation, we observed significant latency and occasional "hallucinations" where it would invent field names not in our schema. We had to implement strict validation and fallback logic.

**Performance metrics (averaged over 47 runs):**
* **Total workflow duration:** 2.1 minutes (compared to ~15 minutes manual).
* **API call success rate:** 100% for our internal endpoints.
* **Document generation accuracy:** 87% without manual correction (required post-processing for the remaining 13%).
* **Cost:** Approximately $0.85 per onboarded customer at our volume.

The main pitfall was the lack of deterministic execution for complex logic. We eventually refactored our flow to use Lindy primarily as an orchestrator calling our own deterministic microservices for business logic, which improved reliability.

**Configuration snippet for the primary webhook trigger:**
```yaml
trigger:
type: webhook
path: /onboarding/new-customer
security:
- type: api_key
key: x-api-key
actions:
- name: fetch_customer_data
type: http_request
endpoint: "{{internal_api_base}}/customers/{{trigger.body.customer_id}}"
method: GET
```

In summary, Lindy provided rapid prototyping capabilities but required architectural adjustments for production-grade reliability. It excels as an orchestration layer but should not be treated as a deterministic workflow engine for mission-critical business logic.

benchmark or bust


benchmark or bust


   
Quote
(@harryj)
Estimable Member
Joined: 3 weeks ago
Posts: 175
 

Interesting. That latency with document generation is familiar. We found the same thing in our service desk - the agentic tasks are great for routing, but for anything that needs consistent formatting (like a knowledge base article draft), they can drift.

>occasional "hallucinations" where it would invent field names

We solved this by creating a "template step" in the flow using a separate tool, then feeding that result back to Lindy for the final assembly. Adds a bit of complexity but it's rock solid now. That's probably your strict validation fallback.

Your success rate on the internal API calls is impressive though. Did you have to do anything special with retry logic, or was it just solid out of the gate?


Automate the boring stuff.


   
ReplyQuote
(@charliep)
Reputable Member
Joined: 3 weeks ago
Posts: 332
 

You stopped at "Document generation accuracy: 87". Is that a percentage? If so, 87% success on a core document means 13% of your welcome packs were wrong. That's not a rounding error, that's a customer service incident waiting to happen. Did you quantify the cost of those errors vs. the manual time saved?


Your stack is too complicated.


   
ReplyQuote
(@emmal)
Estimable Member
Joined: 3 weeks ago
Posts: 145
 

That 87% accuracy on a document is exactly the kind of detail I'd be worried about. How did you handle the 13% that failed? Did you have a person review every document before it went out, or was there a post-send audit that caught errors?



   
ReplyQuote