Custom Monitoring
Themes tell you what people are talking about. Sentiment tells you how they feel. Custom Monitoring tells you when something specific has happened (a safety risk in an open-ended response, a churn signal in a support ticket, a feature request buried in a Trustpilot review) and routes that signal to the right people, automatically.
You do this by defining monitors: rules you write up front, rather than patterns the AI infers on its own. Where themes are emergent, a monitor is deliberate: you decide what matters to your team, and BAI Analytics watches every incoming response for it. A monitor can watch a single source, or every source in an entire Feedback Group, continuously, with its own alerts and trend line over time. The setup and detection mechanics are the same either way; scope is just a choice you make when you create one.
Monitors work across every kind of feedback BAI Analytics ingests: surveys, uploads, connector tickets, and scraped reviews. For where they're stored and how they roll up across a group, see Feedback Groups. For surveys and uploads, see Creating a Survey and Uploading an Existing Dataset.
When to use a monitor
Reach for a monitor when you know in advance that a particular signal needs to be watched, not just measured.
Risk monitoring: safety mentions in employee or student feedback, compliance concerns in customer support tickets, escalation signals in partner surveys.
Operational triggers: churn risk in NPS comments, urgent customer issues in support data, regulatory mentions in scraped reviews.
Opportunity detection: feature requests, competitor mentions, positive testimonials worth amplifying.
Routing & escalation: alerting the right team the moment a relevant comment lands, instead of waiting for someone to read the analysis.
Monitors are not a replacement for themes. Themes surface what's emergent in the data; monitors surface what's important whether or not it's frequent.
Anatomy of a monitor
Most monitors are topic monitors: they describe a signal in plain language and the AI reads every comment for it. (A second kind, the score monitor, watches numeric answers instead; see Score monitors below.) A topic monitor has three layers:
1. The monitor itself
A short name and a description of what you're watching for. Example: "Safety or Well-Being Risk". The description is the most important part, because it is what the AI uses to decide whether a comment matches.
2. Sub-categories
Up to five more specific categories within the monitor. Example sub-categories for Safety or Well-Being Risk: Potential Risk / Warning Sign, Near Miss / Incident Without Injury, Confirmed Harm or Adverse Event. Sub-categories let you triage at scale: all safety mentions are caught, but the team handling confirmed incidents doesn't need to wade through early warning signs. If you leave sub-categories empty, the AI generates them automatically from the matched comments.
3. The detection result on a comment
When the AI determines a comment matches a monitor, it stores three things on the comment:
The monitor name.
The matching sub-category (or Others if the comment fits the monitor but no specific sub-category).
A short explanation of why it matched (shown as Why captured), taken from the language of the comment itself.
A single comment can match multiple monitors simultaneously: a customer ticket can be both a churn risk and a feature request, and BAI Analytics will record both.
Where monitors live: the Monitor Library and applied monitors
There are two places a monitor definition can exist, and the difference matters once you start reusing monitors across groups.
The Monitor Library is your organisation's shared collection of reusable definitions: the eight built-in monitors plus everything your team has created, imported, or generated. Anyone in the organisation can browse it and apply from it.
An applied monitor is a frozen copy that belongs to one Feedback Group or one source. Applying a Library monitor copies its definition at that moment; later edits to the Library entry never silently change what is running on your data.
When a Library definition changes after you applied it, the applied monitor shows "The Library definition has changed" with a Use update action. Using the update replaces any local edits you made to that applied monitor, and you can then re-scan to apply the new definition to existing comments. Deleting a Library monitor does not stop the copies already applied to groups; they keep running with their frozen definition.
The predefined library
BAI Analytics ships with eight built-in monitors, fully translated into the languages BAI Analytics supports. They appear in the Built-in folder of the Monitor Library and cover the operational signals most teams ask for first:
Urgency or Critical Situation
Comments that need immediate attention: outages, urgent business risks, time-sensitive incidents.
Safety or Well-Being Risk
Physical, mental, or emotional safety concerns from respondents, employees, students, or customers.
Ethical, Legal, or Compliance Concern
Mentions of legal exposure, regulatory issues, ethical breaches, or policy violations.
Escalation or Relationship Risk
Comments that suggest a relationship is deteriorating: churn-adjacent, partner conflict, key-account dissatisfaction.
Integrity or Misuse Concern
Suspected fraud, abuse, plagiarism, gaming of metrics, or other integrity issues.
Customer Churn Risk
Direct or implicit signals that a customer or account is preparing to leave.
Feature Request
Suggestions for new functionality, often hidden inside complaints or general feedback.
Positive Feedback
Strong, quotable testimonials worth amplifying: for marketing, internal recognition, or product validation.
Each built-in monitor comes with a default name, description, and a starter set of sub-categories. Built-in monitors themselves are read-only: saving a change to one creates an editable copy in your Library and leaves the original untouched.
Managing the Monitor Library
Open the Library with Manage Library from any monitor picker, or from the Custom Monitoring panel of a Feedback Group. A Back button at the top returns you to the group you came from.
Creating monitors in the Library
New monitor: describe what to detect. With AI assist on, BAI Analytics generates a concise name and description for you; switch it off to type the Monitor name yourself. Each monitor can then be edited on two tabs, Description and Sub-categories.
Generate with AI: point the generator at a question and choose how many monitors to create (1 to 10 per run). It proposes monitors based on patterns in the responses and skips any that duplicate monitors you already have.
Import monitors from CSV or Excel: see Bulk-importing monitors below.
Every Library monitor shows where it is in use (Used in N groups · M sources), so you can tell a workhorse definition from an experiment before you edit or delete it. Deleting a Library monitor removes it for everyone in your organisation; historical analysis results that used it stay intact.
Folders
Folders keep a large Library manageable. Your own folders are listed first, followed by Built-in and Uncategorized (monitors that haven't been placed in a folder yet).
New folder gives a folder a name, an icon, a colour, and an optional description, and lets you add monitors to it straight away.
From a folder's menu you can Rename / edit, Duplicate folder, Hide folder, Export to CSV, or Delete folder. When deleting, choose Keep the monitors (they move to Uncategorized) or Delete the monitors too.
From a monitor's menu you can Edit, Move to folder, Duplicate, Hide or Unhide, and Delete. Drag monitors and folders to reorder them.
Select mode lets you tick several monitors at once and Move, Duplicate, Hide, or Delete them together.
Hidden monitors and folders are tucked out of the default view; Show hidden brings them back. A hidden monitor that is already applied to a group keeps running.
Setting up monitors
You can set a monitor up across an entire Feedback Group, or on a single source. The output looks the same either way, a monitor watching for matches, but where you configure it and what it applies to differ.
Across a whole Feedback Group (recommended)
Open a Feedback Group, switch to the Custom Monitoring tab, then click Manage monitoring to open the Custom Monitoring panel. Two ways to start a monitor there:
New monitor: describe what the monitor should detect, then choose Generate the name for me or Set the name myself. Under Coverage, watch All current sources or pick specific ones, and decide whether to Include sources added later. Tick Save a reusable copy to the Monitor Library if other groups should be able to apply the same definition.
From Library: pick one or more saved or built-in monitors from your Library in a single multi-select picker and add them all at once. This picker is selection-only: to edit definitions or organise folders, use Manage Library.
Click Create monitor (or Create & run N monitors) to start detection straight away, or Create draft to define the monitor now and choose sources later. A monitor with no sources selected is always saved as a draft, and drafts don't run detection, so they cost nothing until you give them sources. The panel shows an estimate of how many scans an apply will trigger before you confirm.
Automatic coverage of new sources
Every group-level topic monitor has an Include sources added later setting: a checkbox when you create it, and a toggle on each monitor row next to the alert bell.
On (the default for newly created monitors): whenever a source is added to the group (an upload, a new survey, a connector import, an agent run, or data pushed through the API), the monitor starts watching it immediately. Detection is seeded before the source's first analysis, so matches show up on the first pass with no extra scan.
Off: the monitor watches only the sources you explicitly selected. The panel shows an amber "N sources not covered" cue when coverage has gaps, with Add sources to extend it.
Monitors that existed before this setting was introduced keep manual coverage until you switch the toggle on, so nothing starts consuming your allowance without an explicit choice.
On a single source
Monitors can also be attached directly to the open-ended questions of one source:
During survey creation: in the builder, every Long Answer question has a Custom Monitoring picker. Monitors applied during creation start running on the very first response. (Short Answer questions are not analysed for monitors, so the picker doesn't appear on them.)
From the analysis view: open the source's qualitative analysis, switch to the Custom Monitoring tab, and click Edit monitors. Toggle monitors on or off per question, then Apply Changes. BAI Analytics re-runs detection across all historical comments so the analysis reflects the new list.
Creating a monitor on the spot: from the Custom Monitoring tab you can also describe a new monitor inline, in Auto mode (the AI names it) or Manual mode (you name it), and tick Save to Monitor Library for reuse so it becomes available to the rest of your organisation.
On connector and scraper data: connector imports and scraped data produce open-ended fields the same way a survey or upload does. Monitors configured on the question apply to every ticket or review that lands in it, on every sync, automatically.
Tips for a strong monitor
Lead with the signal you want to catch, not the wording. Describe the meaning a comment must convey, not specific phrases. "Mentions of regulatory or legal exposure (lawsuits, audits, regulator inquiries, compliance violations)" outperforms "contains the word 'lawsuit'."
Use sub-categories only when triage matters. If your team handles every match the same way, a monitor with no sub-categories is enough. Sub-categories pay off when different sub-types go to different reviewers.
Avoid overlap with other monitors. BAI Analytics merges near-identical monitors automatically, but two monitors with very similar descriptions ("Customer Churn Risk" and "At-Risk Account") will both fire on the same comments and add noise.
Bulk-importing monitors
If you already maintain a monitor taxonomy elsewhere, import it in one go instead of recreating each one by hand. In the Monitor Library, click Import monitors from CSV or Excel to open Bulk import monitors.
Upload a CSV or Excel file with two columns: the monitor's title (up to 100 characters) and its description (up to 1,000 characters). An optional third column lists sub-categories. A header row is recognised automatically, and Download example .csv gives you a starting template.
Up to 200 monitors per import.
Choose where the monitors land under Folder: a New folder, an Existing one, or No folder.
You get a preview with per-row validation before anything is saved. If a row's title matches an existing Library monitor, choose Keep as duplicate or Overwrite; for duplicates inside the file, choose Keep (renamed) or Overwrite earlier. Either choice can be applied to every collision at once.
Score monitors (quantitative alerts)
Monitors are not limited to text. A score monitor watches a quantitative question (NPS or a numeric scale) and counts new answers that match a condition you set, for example "NPS at or below 6" or "Scale below 3".
To create one, open Manage monitoring on the Feedback Group and switch Monitor type from Topic to Score, then pick:
The scores to watch: NPS (0 to 10) or Scale (1 to 10).
A condition: at or below, below, at or above, above, or exactly a value.
The sources to watch. Score monitors always watch an explicit list of sources; they don't pick up sources added later.
Score monitors reuse the same alerting as topic monitors: the per-monitor alert bell, the "Alert when N new matching scores arrive" threshold, and the group's recipients, channels, and frequency (see Alerts below).
Because matching is a plain numeric comparison, score monitors use no AI credits: no detection runs and no analysis is triggered. Conditions are evaluated every few minutes as new responses land, and counting starts from the moment the monitor is created, so you are never alerted about a backlog of old scores. Editing the condition restarts the count from that point for the same reason.
How detection works
Detection is AI-based, not keyword-based. The model reads each comment in context, decides whether it matches each configured monitor, picks the best sub-category if a match is found, and records a short explanation in the language of the comment.
When detection runs
As responses arrive: new survey responses, upload rows, connector tickets, and scraped items are scanned shortly after they're analysed, rather than waiting for a full analysis pass to finish. New matches show up on the Custom Monitoring tab and trigger notifications without any manual action.
On demand, per monitor: in the Custom Monitoring panel, open Manage sources & scanning on a monitor to see each watched source's state (Up to date · N scanned, Scan N new comments, or the number of sources that couldn't be scanned). Re-scan all re-evaluates every comment, which is what you want after editing a monitor's description; the panel reminds you with "Description changed, re-scan to apply it to existing comments." Refresh re-tallies existing detections into the grouped view without scanning anything.
On a source's own analysis: when you change the monitor list with Edit monitors and Apply Changes, BAI Analytics re-runs detection across the source's historical data so the whole analysis reflects the new rules.
Detection mechanics in brief
The detection step batches comments and monitors together for efficiency and screens out weak matches so results stay precise without you having to dismiss false positives by hand.
Multilingual: detection works in every language BAI Analytics supports, including French and Spanish.
A single comment can match many monitors at once. All matches are stored.
Sub-category fallback: if a comment matches a monitor but no specific sub-category, it lands under Others, visible in the UI as its own bucket so it never goes silently unreviewed.
Re-running
Editing a monitor's definition does not lose the old data. A re-scan:
Loads every historical comment in the analysis.
Re-evaluates each comment against the new definition.
Updates the results in place.
Reports the monitor's current total in any alert it triggers, so the number in the alert always matches the number on the dashboard.
Re-runs run as background jobs, so you can keep working while they finish. A progress indicator shows which sources are being checked ("Detecting 'Churn Risk' across 2/5 sources"), and the monitor is announced as live when it's ready to review.
Reviewing matches
The Custom Monitoring tab, on a source's qualitative analysis or on a Feedback Group, is the primary review surface.
On a Feedback Group
Each monitor is a card with its total mentions, the number of sources it watches, and a trend indicator (New, No change, or the change versus the previous period). Click Show trend by period to see the mention count period by period. The trend only ever shows the group's current period granularity, so switching from weekly to monthly periods never leaves stale weekly points in the chart.
A monitor that is applied but hasn't matched anything yet stays visible as No matches yet, so you can tell an active monitor with zero hits apart from a deleted one. When you look at a single period, monitors with nothing in that period are greyed out with No matches in this period; they are still clickable.
Open a monitor to see how it varies by source: a table of every contributing source with its Presence, Sentiment, and how it compares with the overall picture (Above overall, Below overall, or Aligned with overall). Select a source row to focus the interpretation and evidence on that source without leaving the grouped view, or use Open [source] analysis to jump to that source's full individual analysis.
On a single source
Applied monitors are listed with their state: a count of captured items, 0 matches, Scanning, or Scan failed (retry from Manage monitoring on the group).
Pick a monitor to see its captured comments, each with the matching sub-category, the Why captured explanation, and sentiment. Filter by sub-category and search within the comments. Respondent Context shows the full response the comment came from, and View Definition shows the criteria the AI used.
Identify Sub-Categories asks the AI to organise a monitor's matches into sub-categories after the fact; it needs a minimum number of matched comments before it can run.
Merge sub-categories: select two or more sub-categories of a monitor and merge them into one that holds all their comments. Give the merged sub-category a name, or leave it blank to name it automatically. Merging cannot be undone.
Exporting
From the Export action on the Custom Monitoring tab, choose Raw Data Excel File to export matched comments alongside their Sub-category, Why captured explanation, sentiment, and any metadata columns you select, or Download PDF for a shareable summary. Exports respect the sub-category and search filters you have active.
Alerts (Monitor Notifications)
Monitors are most useful when they reach a human quickly. Delivery is configured once per Feedback Group, shared across every monitor on it, under Alert recipients & delivery in the Custom Monitoring panel (the Monitor Notifications settings), so you can wire up different recipients for different programmes (Customer Support EU vs Engineering Bugs vs Campus Life Insights).
Each monitor then has its own controls on its row:
An alert bell to turn alerts on or off for that monitor.
Its own threshold: "Alert when N new mentions arrive" (or new matching scores for a score monitor). Leave it on default to use the group's minimum threshold.
Its own Recipients: Everyone (default) sends to the whole group roster; Custom lets you tick, per channel, exactly who should hear about this monitor. You can only pick channels the group has enabled and recipients who have a contact for that channel; an amber No recipients selected warning tells you when a monitor's alerts would go nowhere.
Configurable per Feedback Group
For each group you can set:
Enable notifications: the master switch.
Notification channels: Email, SMS, and/or Webhook (an incoming webhook for Slack or Microsoft Teams; the settings panel links to where each platform issues one).
Frequency:
Immediate: fires as soon as a monitor is triggered.
Daily digest: accumulates hits and sends them once per day at a chosen Hour and Timezone.
Weekly digest: same, but once a week on a chosen Day of week.
Recipients: a list of people, each with a Name and an Email, Phone (E.164), and/or Webhook URL with its Platform. Recipients are scoped to the group, not to a single user account, so on-call rotations can be modelled by editing the recipient list.
Monitor filter: All monitors by default, or Specific monitors (e.g. only Safety and Urgency).
Minimum threshold: the smallest number of new matches worth notifying anyone about (default 1). Useful for daily digests on noisy datasets where a single match isn't worth interrupting anyone.
Behaviour
Everything that arrives after alerting is switched on can alert, including the very first match. Nothing that arrived before you enabled alerts is sent, so turning alerts on never floods anyone with a backlog. This holds whether you enable the group setting, flip a monitor's bell on later, or add a brand-new source to a group that already alerts: its first batch of data can trigger an alert.
Immediate notifications are sent as soon as a comment has been analysed.
Digest notifications are collected and sent on the schedule you choose. A recipient set to "daily at 09:00 Europe/Paris", for example, reliably receives their digest in that window. If a digest fails to deliver, it is kept and retried rather than lost.
Empty digests are skipped. If nothing matches in the digest window, no message is sent.
Webhook alerts arrive as a message in the Slack or Teams channel the webhook posts to, with the same content as the email.
Monitors in Evolution views
If your Feedback Group tracks periods over time, monitors can be plotted as Evolution widgets. A monitor widget shows its mention rate as % of responses by default, so a spike in mentions is read against how much feedback arrived that period; switch Display as to Count for raw numbers. Faint volume bars behind the line show how many responses each period had, and periods with fewer than 30 responses are drawn as hollow points marked Low sample, so a dramatic-looking rate built on a handful of answers is easy to spot. See Feedback Groups for how periods and Evolution views work.
Limits
150 monitors per analysis (built-in + custom + Library, on a single source).
200 monitors per bulk import.
5 sub-categories per monitor.
100 characters per name; 1,000 characters per description.
Generate with AI creates up to 10 monitors per run, and up to 150 AI-generated monitors in total.
Best practices
Start with one or two monitors, not ten. Most teams over-monitor at first and drown in low-priority hits. Add monitors as the need surfaces.
Make descriptions specific. A monitor's description is the AI's brief. Vague monitors catch too much and miss too little; precise ones do the opposite.
Use sub-categories only where triage diverges. If safety reports all go to the same person, Safety or Well-Being Risk without sub-categories is fine. Add them when a real human routing rule exists.
Save proven monitors to the Library. A definition that works for one programme often works for the next; tick Save a reusable copy to the Monitor Library when you create it, and group related monitors into folders.
Set a threshold before turning on alerts. A threshold of 1 on a busy group can mean constant notifications; start higher and lower it if you're missing things that matter.
Route alerts per monitor. Give safety and compliance monitors their own recipients rather than paging the whole roster for every feature request.
Re-scan after every meaningful definition change. Edits only apply going forward unless you re-scan; re-scanning brings the historical data into line with current rules.
Leave Include sources added later on. The most common monitoring failure is a source added after setup that nobody remembered to cover. Auto-coverage closes that gap; switch it off only for monitors that are deliberately scoped to specific sources.
Match monitor scope to Feedback Group scope. A Customer Churn Risk monitor belongs on customer-feedback groups, not on employee-pulse surveys. Monitors only catch what's actually in the data they run on.
Last updated