When it acts
- Escalation from detected API error
- Human agent decision in Inbox
Connect GitHub and answer "is this a bug on your side?"
When Intake detects a problem requiring technical intervention, it creates a GitHub issue including chat history, account plan, and the steps it already tried to resolve.
What it solves
"Is this a bug on your side?", answered with a fact
When a customer reports something odd, the honest answer usually takes hours: someone has to check whether it is already reported, already fixed and in which release. The agent checks issues and releases before replying, so the first answer already says whether it is known and when, instead of "we will look into it".
What it solves
Engineering stops acting as translator
Most escalations to engineering are checks, not fixes: seeing whether the customer error matches an open one. The agent eats that. What reaches a developer is what genuinely needs a developer, and it arrives with the version, the error message and the related issue.
What it solves
The heads-up lands when it is fixed
The worst part is not having a bug: it is finding out on your own that it was fixed three weeks ago. With GitHub connected, the agent knows when the issue affecting that conversation closes and can tell whoever reported it. Follow-up stops depending on someone remembering.
What it does
What the connection triggers and what the agent does with it
An integration is not useful for being on the list: it is useful for what it lets the agent do. This is what GitHub puts on the table, and what the agent does with it without anyone watching.
What it can do
- Create GitHub Issue
- Link conversation to existing Issue
- Notify upon Issue close
How GitHub helps the agent resolve with context
Three concrete things that change the team day, not a feature list.
Issues with context
Developers see right in GitHub which user has the problem and what Intake tried, saving back-and-forth.
Real priority
Sync the volume of repeated complaints from Intake to know exactly which bug affects more customers.
Close the loop
When the issue is resolved in code, Intake can automatically notify the customer through the same support thread.
How it works
Three steps, and only the first needs a GitHub admin. The rest you change later without reconnecting anything.
Authorise the connection
You open the integrations panel, pick GitHub and authorise access with the account your team already uses. You need to be an admin in GitHub, so if you are not, this is the only step you will have to ask someone for.
You choose what the agent sees
You tick the channels, events and account fields it can reach. What you do not tick does not exist for it, and you can change that whenever you want without reconnecting anything.
It answers with that context
From the first conversation the agent looks that data up before replying, resolves what it can close on its own and passes to a person what it cannot, with the case already assembled.
Frequently asked questions
How long does connecting GitHub take?
Minutes, not an afternoon. You authorise access and choose what it can see; nothing needs rewriting and no development work is needed to start.
Can I revoke access later?
Yes, and from either side: revoking the connection in Intake or withdrawing the permission from GitHub. The agent stops reading that data immediately and keeps answering with the rest.
Does using GitHub cost extra?
No. Every integration sits inside the per-resolved-conversation price: 0.41 EUR on annual billing. There is no add-on to buy and no call meter.
What happens if GitHub stops responding?
The agent answers with what it does have and, if the question depended on that data, hands off to a person explaining why. It never invents the value it could not look up.
Are issues created automatically?
You control the flow. Intake can create issues automatically on certain API errors, or wait for the support team to click a button.
Does the customer know about status changes?
Yes, Intake keeps the thread alive and can notify the customer when the issue moves to "Done".
