Most marketing teams find out that an AI answer changed by accident. Someone tries a question in ChatGPT, notices a competitor where you used to be, and then spends a morning working out who should look at it. This guide shows you how to set up ai mention alerts, including brand mention alerts chatbots can trigger, so a changed answer reaches a named person in Slack or email, with the original answer attached. You'll need access to your monitoring workspace, an alert policy your team has already agreed on, and about an afternoon.
One thing to know before you start. DeepSmith tracks your prompts on a schedule, keeps every answer, and gives you read-only API access to the data. If you're still choosing among AI brand monitoring tools, check what each one offers for alerts and data access. The route in this guide doesn't depend on a built-in alert screen. The alerting part runs in a workflow tool (we'll use n8n as the example) that reads your data, checks it against your rules, and sends the message.
What you need before you start
- Access to your monitoring workspace, with permission to change brand settings, prompts, and collection frequency.
- An alert policy your team already has. This guide doesn't decide what counts as a meaningful change. That's a separate decision, and the guide on alert thresholds covers it. Bring whatever rule you have, even if it's a rough one.
- A named marketing owner for the alerts and a named automation owner for the workflow itself. On a small team they can be the same person.
- A Slack channel or shared email address that the right people actually read.
- Permission to authorize a Slack app, if you're using Slack, or an SMTP account, if you're using email.
- A safe place for credentials, such as a secrets manager, kept out of screenshots and shared documents.
With DeepSmith, API keys belong to one workspace, and only workspace owners can create and revoke them. A key acts as the person who created it, so if that person leaves, the integration can break.
Step 1: Fix the prompts and brand identity you'll monitor
Before you build anything, decide exactly what the alerts will cover. Alerts only describe the prompts you track, not everything people say about you in chatbots.
Record these things in one short note:
- The brand's canonical name, and the variants you want recognized (a short form, a product name, a common spelling).
- The list of tracked buyer prompts.
- The engines your plan covers.
- A prompt-set version and the date it took effect.
In DeepSmith, the Prompts area under AI Visibility shows the questions you track. Discover Prompts can suggest a starter set from your product, persona, and buyer-stage context, and you should read each suggestion before you adopt it. Settings holds your brand definition, your competitors, and how often collection runs. The guide on tracking prompts explains how a prompt list turns into visibility numbers if you need help building the list.
Engines depend on your plan. Pro tracks ChatGPT, Grow adds Perplexity, Scale adds Gemini, and Enterprise covers all ten engines. Plans also set how many prompts you can track, which is 50 on Pro, 100 on Grow, and 200 on Scale. The roundup of LLM monitoring tools compares engine coverage across tools.
You're done with this step when someone other than you can say which brand, which prompts, and which engines the alerts cover, and can tell the difference between an answer that changed and a setup that changed.
Common mistake: Changing the prompts or the brand matching and then comparing results as if nothing moved. If a product name or a shortened company name stops matching, it can look like your brand disappeared when the answer is really the same. Keep the version note up to date and check the underlying answer before you believe a drop. Versioning is our suggestion for your workflow, not a platform feature.
Step 2: Confirm collection and read the answer history
Next, check that the system is collecting what you think it is. A notification built on top of missing data will only send you confusing messages.
DeepSmith checks your prompts on the schedule you set and captures every answer. The prompt history lets you read what each engine said over time, along with the mention result and citation result for each prompt. Open a few of your tracked prompts and read the real answers. Confirm that the engine you care about is covered by your plan, and note where to find the prompt, the engine, and the collection time for each answer.
Keep two ideas apart as you do this, because your alerts depend on them.
A mention means your brand is named in the text of the answer, and a citation means a source is linked next to it. An engine can name your brand without linking your site, and it can link one of your pages without naming you. If you want an alert when ai omits my brand, you need to look at whether the brand was named, and treat citations as extra context. A missing citation alone isn't evidence that you were left out. If you're weighing AI visibility tools, look for this same split between mentions and citations.
Collection and notification are also separate. Running your workflow every ten minutes won't produce newer answers than your collection schedule does, so use the collection frequency you already have rather than promising continuous monitoring.
You're done when you can point to a successfully captured answer for each prompt and engine pair you plan to alert on. The first answer you capture simply gives the workflow something to compare against later.
Step 3: Connect your monitoring data to a workflow
Now you need a way to get the data out. For DeepSmith, the dependable foundation is the documented read API. The webhook events DeepSmith documents cover content status, Opportunity Agent runs, agent tasks, and Deep IQ analysis, so they won't tell you when a mention changes. Use the API and poll it on a schedule. If you don't have an engineer to help, the list of monitoring tools for marketers shows which ones a non-technical team can run.
To create a key:
- Go to Settings, then API keys.
- Select Create key.
- Give it a descriptive name and choose an expiry date.
- Keep only the scopes the integration needs. Visibility data uses the
visibility:readscope, and new keys start with all five scopes, so remove the extras. - Copy the key right away. It's shown only once.
- Store it in your credential store.
- Test it with a
GETrequest to/me.
The API accepts the key as either Authorization: Bearer YOUR_API_KEY or X-API-KEY: YOUR_API_KEY. Pick one. In n8n, add an HTTP Request node, set the method to GET, and use a generic Header auth credential so the key never sits in the node's visible settings. Responses come back wrapped with code, messages, and data, and rates are fractions between 0 and 1. Reads don't spend credits, and you get 120 requests per minute per workspace, shared across all its keys.
There's one gap to be honest about. A successful /me call proves the key works. It doesn't prove you can pull answers. The exact answer-list endpoint, its filters, how it pages through results, and which fields it returns need to be confirmed from the API reference before you turn on automated checks, and this guide doesn't guess at them. Open the reference at docs.deepsmith.ai and map the fields you need (prompt, engine, collection time, answer text, brand result) before you go further.
You're done when authentication works and you can retrieve real answer records for your prompts.
Common mistake: Giving the key every scope, using a key from the wrong workspace, or pasting it into a screenshot. If it leaks, revoke it, and it stops working on the next request.
Step 4: Schedule the workflow and give it a memory
A workflow that only runs once isn't an alert. You need a schedule, and you need the workflow to remember what it has already seen.
In n8n, add a Schedule Trigger, add a trigger rule, pick the interval, and fill in the matching fields. The Schedule Trigger node lets you set the workflow timezone explicitly, and you should, because otherwise it uses the instance timezone and your timestamps can confuse people. Then save and publish the workflow. A manual test run doesn't mean the schedule is live. Pick a polling interval that makes sense next to your collection schedule. This guide doesn't recommend one, and a polling interval isn't an alert threshold.
For memory, create an n8n Data table. Open the project's Data tables tab, choose Create Data table, name it, and add columns. The Data tables documentation describes them as meant for light to moderate storage, with a default size limit of 50 MB per table. Tables in a project are visible to project members, so think about who can see answer excerpts you store there.
Store the previous observations you may compare against, the IDs of answers you've already processed, alert events waiting to be sent, and the delivery status for each destination.
Keep three simple local records: an observation (prompt, engine, collection time, answer text, brand result), an alert event (the rule that fired, the observations behind it, the owner), and a delivery record (the event, the destination, and whether it's pending, sent, or failed). The field names are yours to choose, since they're your own records and not DeepSmith response fields.
You're done when a scheduled run happens without you clicking anything, the stored data is still there on the next run, and the workflow recognizes an answer it has already handled.
Common mistake: Keeping the history only inside a single execution, leaving the workflow unpublished, or comparing an answer from one engine with an answer from a different prompt.
Step 5: Apply your existing rule to complete answers
With data flowing and a memory in place, you can check each new answer against your team's rule. The rule itself comes from your policy. What this step adds is the discipline of only judging answers that were collected properly.
A good order for each run is to check the response structure, confirm the answer was collected successfully, work out which combination it belongs to (workspace, brand, prompt version, engine, and locale where you have one), check whether you've already processed it, load the previous comparable answer if your rule needs one, apply your rule, and save the observation plus any alert that should go out.
For an alert when ai omits my brand, use the brand result that your monitoring data gives you, because that's the cleanest signal of whether the brand was named. If you have to match names yourself, write down that it's custom matching and use the same brand variants you recorded in step 1. Don't treat a zero citation count, an empty response, a failed engine call, or an engine your plan doesn't cover as an omission. A missing answer and an answer that leaves you out are different events, and only the second one is about your brand.
When the alert is about how an engine describes you, keep the before and after answer text so a person can read both. Don't assume the API gives you a sentiment score or a wording-change flag unless the response you've pulled contains one. If you want a sense of tools that score tone, the roundup of AI brand sentiment tools is a good place to compare.
You're done when you've fed the workflow test answers that exercise your rule, and a failed or incomplete collection doesn't create a brand-omission message.
Common mistake: Inventing a new trigger while you're busy configuring delivery. If the rule needs to change, change the policy first and then the workflow.
Step 6: Connect Slack or email to the right place
Set up the destination on its own, apart from the rule, and send a clearly labeled test before anything real goes through it.
Slack
- Create a Slack app, or open the settings for one you already have.
- Select Incoming Webhooks.
- Turn on Activate Incoming Webhooks.
- Select Add New Webhook to Workspace.
- Choose the channel you want and select Authorize.
- Copy the webhook address into your protected workflow configuration.
- Send an HTTP POST with the content type set to application/json and a body that has a
textvalue.
Here's a test message you can use:
{
"text": "TEST: AI mention alert routing check. No live brand event is being reported."
}
Slack normally answers with HTTP 200 and the text ok. Check that the message appeared in the channel you meant, too. If the channel is private, the person adding the webhook has to be a member of it first. The incoming webhooks documentation is clear that a payload can't override the channel, username, or icon. If different teams need different channels, set up a separate webhook for each.
Add a Send Email node, select or create an SMTP account credential, use the Send operation, and fill in From Email, To Email, and Subject. Choose Text, HTML, or Both for the format, add CC, BCC, or Reply To if your routing needs them, then send a labeled test and confirm someone received it.
You can put several addresses in the To field separated by commas. The Send Email node has an option to ignore certificate errors, and it's best left off. This node can't set threading headers, so each alert arrives as a new conversation.
You're done when the test message lands where it should and the right people can see it.
Step 7: Give every alert an owner and the evidence
An alert with no owner is just noise in a channel. Decide in advance who gets which kind of event. The table below is a starting point for your own routing, and it's a suggestion for how to organize your team, not something DeepSmith does for you.
| Event | Primary owner | Supporting owner |
|---|---|---|
| Brand left out of a tracked buyer answer | AEO or content marketing lead | Topic or product marketing owner |
| Changed product description or apparent factual error | Product marketing | Product specialist |
| API, scheduler, parsing, or delivery failure | Automation owner or marketing operations | Workspace owner |
| Nobody acknowledges the alert | Named backup | Marketing lead |
Larger organizations with governance needs can compare enterprise monitoring tools, and agencies sending alerts for many clients can look at monitoring tools for agencies.
Each message should carry enough that the owner doesn't have to go hunting: the brand and workspace, the event label from your rule, the exact prompt, the engine, the collection time with its timezone, your prompt-set version, the previous and current observation when your rule compares the two, a short answer excerpt with a way to open the full answer, citation details shown separately from the mention result, the owner, the backup, the next action, and a stable event ID so repeats are easy to spot.
Here's a template you can adapt. It's our own layout, not a DeepSmith payload:
AI mention alert: [event label from your rule]
Brand: [brand]
Prompt: [exact prompt]
Engine: [engine]
Collected: [timestamp and timezone]
Configuration: [prompt-set version]
Previous observation: [where relevant]
Current observation: [result]
Answer excerpt: [short excerpt]
Citation context: [separate source information]
Owner: [named person or team]
Backup: [named backup]
Next action: Open the captured answer and review it under our usual process.
Event ID: [stable identifier]
If the monitoring data gives you a link to the answer, use it. If it doesn't, include the identifiers and short directions for finding the answer in the workspace. Please don't make up a link format. Recipients also need access to the evidence. A message that points to a workspace someone can't open doesn't help them.
You're done when the primary owner and the backup can both open the evidence and say who's handling the next step.
Step 8: Test the whole workflow and write down the handoff
Test each part on its own: how failed collections are handled, how the rule is applied, how messages get delivered, and whether a person picks the alert up. Use clearly labeled test observations, and don't change your live reporting just to make an alert show up.
| Test | What should happen |
|---|---|
| A valid answer that matches your rule | An event is created and the right person receives it |
| A failed source request | The failure is logged or routed as an operations issue, and it's not called an omission |
| An empty or broken payload | Processing stops safely and earlier evidence isn't overwritten |
| The same source answer seen twice | The duplicate check catches it |
| Slack or SMTP failure | The event stays pending or failed, visible to the automation owner |
| The key is revoked or expires | The authentication failure is visible to the integration owner |
| A scheduled run | The published workflow runs without a manual start |
Save your records before you move the workflow forward, and mark a delivery as sent only after the destination says it worked. Don't promise exactly-once delivery, since a destination can accept a message while your workflow misses the reply. A stable event ID helps people recognize a repeat.
Then write the handoff down: where the source data comes from, who owns the workflow and the credentials, the destinations, the recipients and their backup, the test results, how to recover, and how to pause notifications without deleting the evidence history.
You're done when a scheduled run finishes, a test alert reaches the right person, that person can inspect the evidence, and a failure would show up for the automation owner.
Common mistake: Testing only the Slack post. Test a failed source request and a failed delivery too, since those are the cases that go quiet.
If something goes wrong
If authentication works but you can't retrieve answers, check that the key has visibility:read and belongs to the right workspace. If the workflow reports an omission after a failed collection, separate the collection status from the brand result and reprocess the record.
What to do next
Put the owner and the backup in the handoff note, and open the evidence the first time a real notification arrives. After the first few, you'll know which labels, excerpts, and owners need adjusting. The next job is tying mentions back to the pages that earn them, and the roundup of monitoring tools for content teams covers that. Reviewing the alerts with the team on a regular schedule keeps them tuned.
If you don't have your prompts and brand settings in place yet, the easiest start is a DeepSmith free trial. It's seven days, and it lets you set up your tracked prompts and read the captured answers before you build the workflow around them. Starting a trial doesn't switch on mention-change notifications by itself, so you'll still do the workflow steps above.
Related guides
- SE Visible Alternatives: 7 Best AI Visibility Trackers for 2026: Compares seven substitutes for SE Ranking's SE Visible: DeepSmith, AthenaHQ, LLMrefs, RankScale, OtterlyAI, Peec AI and Profound.
- Searchify Alternatives: 8 Best AI Engine Visibility Tools for 2026: Reviews eight Searchify alternatives (DeepSmith, LLMrefs, AthenaHQ, Rankscale, Scrunch, Profound, OtterlyAI, Peec AI) using six filters: engine coverage by tier, prompt depth, page-level citation attribution, competitive view, pricing.
- Siftly Alternatives: 8 Best Tools to Track How AI Describes Your Brand in 2026: For teams watching how AI models describe their brand, this ranks eight Siftly alternatives (DeepSmith, Profound, Peec AI, OtterlyAI, LLMrefs, Scrunch, AthenaHQ, Rankscale) on multi-engine tracking, prompt-level sentiment.
- Surfer AI Tracker Alternatives: 7 Best AI Visibility Tools for 2026: Scoped to Surfer's AI Tracker feature rather than its content editor, this details Surfer's five tracked surfaces and plan tiers, then compares seven alternatives (DeepSmith, AthenaHQ, Profound, LLMrefs.
- Troovue Alternatives: 8 Best AI Citability Diagnostic Tools for 2026: Explains why Troovue's 0 to 100 Visibility Eligibility Index is a readiness condition, not a citation outcome, then ranks eight alternatives (DeepSmith, Profound, Peec AI, Scrunch, AthenaHQ, Otterly.
