Linear ↔ Attio: the feedback loop that actually closes
The gap between "customer asked for X" in the CRM and "X shipped" in the product tracker is where trust dies. The CSM forgets to tell the customer. The product team forgets who asked. Two months later the feature ships and nobody closes the loop. We wire Linear into Attio so the loop closes itself. Customer requests in Attio become labelled Linear issues. When the issue ships, Attio automatically marks the request as delivered and pings the CSM to tell the customer.
Direction
Attio ↔ Linear (issues, feedback, feature requests)
Stack
Linear GraphQL, Attio API, n8n
The what
What this integration actually does
The how
How we build it
- 1
Add a Feedback object (or fields on the existing Deal/Account) to capture product feedback in Attio.
- 2
Wire a "Create Linear issue" action that opens the issue with the linked customer in the description, correct team, and a "from-customer" label.
- 3
Subscribe to Linear webhooks on issue state changes.
- 4
On state change → update the Attio Feedback record (status, completion date) and notify the owning CSM.
- 5
Optional: aggregate duplicate requests. When three customers ask for the same thing, the Linear issue lists all three and priority bumps.
- 6
Two-way comments: a Linear update on the issue propagates back to the Attio record as an activity.
Under the hood
What lives inside the pipeline
- Customer context in every Linear issue - ARR, tier, CSM - so PMs know who asked.
- Duplicate detection - similar requests surface as "also requested by" instead of new issues.
- Shipped notifications: CSM gets a Slack DM with a drafted customer update message.
- Bug-to-account linking - bugs filed by enterprise accounts show up in the right account's record.
- Priority hint based on linked ARR - not automatic, but visible to the PM during triage.
Hard-earned lessons
What we learned the hard way
- Don't create Linear issues for every CRM note. The signal-to-noise tanks and the product team stops trusting the feed.
- Label taxonomy matters - "from-customer" + team + area labels. Without them, the product team can't filter incoming requests.
- Status changes in Linear are richer than Attio's usual enum fields - map them thoughtfully (shipped vs closed vs cancelled are different signals to a customer).
- CSM-drafted update messages should be drafted, not sent. Never auto-email a customer that something shipped.
Case study
Entry Agents (our SaaS product)
Problem
Feature requests from EntryLabs users were scattered across Slack, email, and the Linear feedback project. When fixes shipped, nobody closed the loop with the users who asked.
Solution
Attio Feedback object wired to Linear. Every piece of feedback creates a tracked issue; shipping closes the loop with a drafted Slack message to the CSM.
Outcome
Close-the-loop rate went from roughly never to near-100%. Users who get the update reply - it's the single best retention touch we have.
FAQ
Questions we get
Same pattern. Linear is our reference because it's what we use. Jira needs more config around project/issue-type mapping.
Yes. Anyone with Attio access can file - we just label them differently so the product team can triage on source.
Out of scope for this pipeline. This integration is specifically for the customer-feedback loop.
Want this running on your Attio?
Book a free 30-min call. We'll map your use case to what we've already shipped and tell you whether this fits - honestly.
Book a 30-min call