Boring AIBoring AI
Request access
Support/First-party starter playbook

Triage support email

Summarize, search docs and open a ticket.

// what it does
  1. 01Summarize. Read the incoming email from Gmail and distill the customer's issue, the product area, and any error details into a concise summary.
  2. 02Search docs. Search the workspace knowledge base for articles that address the issue, so a known answer can be surfaced quickly.
  3. 03Open a ticket. Create a Jira ticket with the summary, relevant links, and a severity guess, and assign it to the team that owns that product area.
  4. 04Acknowledge. Reply to the customer to confirm we've received their request and share the ticket reference and any immediately helpful doc.
// guardrails in the draft

Do not promise a fix, timeline, or refund in the acknowledgment — confirm receipt and set expectations only.

If the email looks urgent (outage, security, data loss) or is from a VIP account, flag it for immediate human attention rather than only ticketing.

When the product area or owning team is unclear, route to a triage/default queue rather than guessing.

Never share another customer's information in a reply.

Before you publish this playbook

Playbook updated

Prepare the support queue and acknowledgment rules

Use this playbook to turn an incoming Gmail message into a useful Jira ticket and a bounded acknowledgment. Identify the mailbox, Jira project, default triage queue, and ownership rules for product areas. Supply the knowledge articles the team wants the agent to consult. Define what counts as urgent and how a human should be alerted for an outage, possible security issue, data loss, or a VIP request.

Review the external reply action before enabling it. The acknowledgment should confirm receipt and point to the ticket or a relevant article; it should not promise a fix, timeline, or refund. Configure review where your team's policy requires it. A suggested severity is a starting judgment for the support team, not a substitute for the incident process.

Check the ticket and the reply as separate outputs

Use a straightforward question, a message with no clear product area, and an urgent report. Inspect whether the ticket retains the relevant error details and whether its assignment follows the ownership policy. For missing context, the draft should use the triage queue rather than invent a team. Check that a knowledge link actually addresses the request and does not expose another customer's information.

Evaluate the acknowledgment independently of ticket creation. A ticket can be correct while its customer-facing wording is too confident. Read both outputs and the run trace before calling the trial successful. If ticket creation succeeds but the reply fails, confirm the existing ticket before rerunning so the team does not receive duplicate work. Keep the support owner responsible for unresolved cases during the initial rollout.

// more agentic workflows to start from
Data & OpsDaily executive brief

Every morning, digest Linear, Fireflies, Gmail & Calendar into a stack-ranked Slack brief.

Preview the daily executive brief playbookEngineeringWeekly backlog hygiene

Propose and apply reviewed cleanup for stale, duplicate and unowned issues.

Preview the weekly backlog hygiene playbookFinanceInvoice approval routing

Route incoming invoices for approval.

Preview the invoice approval routing playbook

Make triage support email yours.

Request access and we'll start with a private draft. You keep control of the tools, permissions, tests, and publication decision.