Linear “Customer Requests” are a first step. We need more. Linear customer requests helps us better present problems to product, but it does not handle customer validation flows.

Yesterday

This is what I’ve seen in the past:

1. Customer reports bug.
2. Support aggregates, hands off to product.
3. Product fixes bug.

Today

This is what we’re doing at Kernel. I’m calling the customer-facing team “Integrations” in this context.

1. Customer reports bug.
2. Integrations* repros, aggregates, hands off to engineering.
3. Engineering fixes bug.
4. Integrations tests with customer, verifies or re-escalates.

Problem

SaaS or IaaS adoption always requires a customer champion: someone who believes in your service and is willing to do the implementation work. Ownership of that relationship gets muddied over time as multiple teams compete for champion time:

• Infrastructure: incidents
• Sales: upsell or renewal
• Marketing: customer stories, co-marketing, cross-selling
• Product: new releases
• Support: bug fixes

However, champions are your company’s most valuable people, even more than your own employees! You can hire new employees; if you lose a champion, it’s almost impossible to find a new one in that company. This is why sales teams are so protective of their relationships: partly out of selfish interest, but mostly because they understand the relationship is valuable. But this isn’t a communication problem, it’s a prioritization problem — which resolves itself if you have a sorted list. Effectively, you need a per-customer issue tracker.

I’d love to use Linear for this, but two problems:

1. Login requires a Linear account, which we cannot guarantee our customers have.
2. Linear has no cross-account issue dependencies, and we absolutely do not want 200+ customer teams in our Linear account.

GitHub remains the default. We already maintain a per-customer GitHub repo¹, so it’s natural to use the issue tracker inside it. The thread we want: a customer files an issue in their repo, we mirror it to internal Linear, link the two with a “blocked by” relationship, and when Linear closes, the customer issue updates with the resolution. The customer sees a single thread; we see a workflow.

Tomorrow

Invite customers to a GitHub repo. Collaborate on issues and code.

Agents on both sides of a vendor relationship are siloed today: our agent reads our Linear; the customer’s agent reads their tracker. They are gated by human communciation (email, Slack). The shared repo collapses that — both companies’ agents read the same threads, post fixes to the same PRs, inherit the same code context. The repo is the integration spec, the bug tracker, and the deploy target.