Choose signals that deserve review, keep evidence gaps separate from performance issues, and give every alert an owner and a clear next action.
By Sopact · Updated September 12, 2026
Build useful portfolio impact alerts by linking each signal to an agreed outcome, a current source and a response owner. Define what triggers review, how uncertainty is shown and when an alert closes. Test the rule against past examples before relying on it. An alert identifies something that needs attention; it does not establish that an investee has failed or predict what will happen next.
This lesson is for impact and portfolio operations teams monitoring investees or grantees. It addresses risk to intended outcomes, not market-price or credit-risk modeling. Bring the variance review from the previous lesson. Leave with an alert specification and a test log that your team can use with a spreadsheet or a configured platform.
A useful alert starts with a concern that matters to the people or environment the investment intends to benefit. “A number went down” is not enough. State the consequence you are trying to notice and why the chosen signal could be informative.
Impact Frontiers defines impact risk around a material difference between expected and actual impact, viewed from the people or environment experiencing it. Its guidance considers likelihood and severity and distinguishes evidence risk from other risks. Those distinctions matter: weak information and a weak result require different responses.
| Concern | Possible signal | What the signal cannot establish alone |
|---|---|---|
| People may not reach the intended outcome | Reviewed results differ from the agreed expected path | The cause of the difference or the final outcome |
| The team cannot assess progress reliably | Missing coverage, conflicting definitions or stale evidence | That the underlying program is performing poorly |
| Delivery may be interrupted | Partner reports a material staffing, supplier or operational change | The size or certainty of its future effect |
| Some groups may be overlooked | Available disaggregated results or feedback show an issue requiring review | The experience of people not represented in the data |
These are illustrative starting points, not a complete risk framework. Select concerns with the responsible team and people who understand the context. Keep consequential or sensitive issues within the organization’s established review process.
You can review a submission promptly when it arrives, but quarterly observations do not become real-time knowledge of the organization. Distinguish when something happened, when it was recorded, when it reached your system and when someone reviewed it.
For example, a report received in April may describe January through March. An alert created on receipt is current as a processing event, but the underlying observation is historical. Show both dates so the reviewer knows whether to ask for an updated check-in.
Where a timely operational feed or partner check-in is available, it may support more frequent monitoring. Confirm the source, permissions and update cadence. Do not describe a manually uploaded quarterly file as continuous monitoring.
An alert specification should explain why it exists, how it is triggered and what a reviewer should do. Avoid a rule such as “flag risky partners” without a measurable condition or an evidence requirement.
| Field | What to define |
|---|---|
| Purpose | Outcome or commitment and the concern being monitored |
| Source | Required fields, document or check-in; organization and period identifiers |
| Condition | Exact comparison or review rubric, including definition version |
| Evidence gate | What must be present before interpreting the performance signal |
| Freshness | Observation period and when an update becomes overdue |
| Owner and action | Responsible person, review task and agreed response expectation |
| Pause and close rules | When a response, correction or completed review changes the status |
| Audit record | Source, trigger time, reviewer decision, action and rule version |
Use different rules for missing evidence and an observed shortfall. A rate with an unknown denominator should trigger a data clarification, not a confident performance judgment. If a target is zero, do not use a percentage-variance calculation that divides by zero.
Fictional example, continuing the course. Partner A confirms 35 quarterly job starts against an agreed target of 40. Its separate follow-up reports 70% sustained employment among 20 respondents, but the eligible cohort remains unclear.
For this exercise, the team has agreed that a reviewed shortfall greater than 10% triggers a discussion. That is an illustrative local rule, not a recommended universal threshold. The start-count shortfall is 12.5%, so the rule creates a performance-review task. The follow-up rate creates an evidence-clarification task because its comparability is unresolved.
| Alert | Evidence shown | Action and closure |
|---|---|---|
| Quarterly starts need review | 35 actual, 40 target,−5 or −12.5%; confirmed definition and period | Relationship owner reviews the explanation and records an agreed action |
| Follow-up coverage needs clarification | 14 of 20 respondents report employment; eligible cohort unknown | Data owner confirms cohort and coverage, then decides whether a performance comparison is valid |
The first task does not prove that the partner will miss its annual outcome. The second does not prove that outcomes are poor. Keep the two histories linked to the same partner without merging them into an unexplained “high-risk” label.
Track the issue across updates. Use an identifier based on the organization, measure or concern, period and rule. A corrected upload should update the existing review when appropriate, rather than creating another copy of the same task.
Define whether a repeated condition updates an open issue, requires a new checkpoint or represents a genuinely different event. Pause routine notifications when the owner has acknowledged the task and an agreed action is in progress. Resume or escalate only under the documented rule.
For sensitive information, control who can see the supporting evidence. A broad notification can say that review is required without copying restricted details into every recipient’s inbox.
A plausible signal is not a validated predictor. Review examples where the concern occurred and where it did not. Ask whether the rule would have helped someone act sooner, and whether its false alarms would create unnecessary work.
Illustrative test. In a small set of historical records, a rule produces 12 alerts. Reviewers judge eight to warrant the specified action and four to be false alarms. Two additional issues that warranted action were not flagged. In that test, eight of 12 alerts were useful for the defined purpose, and eight of 10 reviewed issues were detected. The sample is too small to establish reliable future predictive performance.
Review why the four false alarms occurred and why the two issues were missed. Do not simply loosen a threshold until the dashboard looks better. Keep a separate set of examples, where available, to check a revised rule rather than measuring improvement only on the cases used to tune it.
Also test operational failures: a changed contact, inaccessible source, duplicate file, late correction, missing denominator and a task whose owner is away. A sound comparison is not enough if the notification never reaches someone who can respond.
AI can help identify candidate issues in narratives, extract values and apply a configured review rubric. Ask it to show the source passage and the uncertainty behind a flag. A phrase such as “staffing difficulties” may warrant a question; it does not, by itself, establish an outcome risk level.
Use a bounded instruction: “Review these authorized updates against the supplied rule. Return the source, relevant statement, rule condition, missing context and proposed review question. Do not infer missing values or assign a risk level when the evidence requirement is unmet.” A person should verify consequential flags and decide the response.
Watch the portfolio reporting demonstration · 2 minutes 16 seconds
A Sopact demonstration of connected portfolio records and reporting. This demonstration introduces connected portfolio reporting. The demonstration shows connected portfolio reporting, not a validated risk-prediction model. Test alert rules and notification support separately.
Bring the two Partner A situations or an authorized example from your portfolio. Check whether the source evidence, definition and reporting period remain connected when a new submission arrives. Test whether the reviewer can distinguish a performance issue from an evidence gap and see the earlier clarification history.
Confirm supported analysis, notification and integration arrangements during setup. Test owner assignment, duplicate handling and closure behavior rather than assuming every route is automatic. The practical goal is a review process that people can trust and sustain, not a promise of perfect prediction.
No. This lesson concerns the delivery and evidence of intended outcomes. Financial risk analysis may inform the wider review but requires its own measures and expertise.
A configured workflow can prepare analysis on receipt. The underlying data still describes its observation period, which may be months earlier. Show both observation and processing dates.
Use shared definitions where appropriate, but set review rules that fit the measure, stage and commitment. Document the rationale and avoid treating an illustrative threshold as a universal standard.
It identifies a condition requiring review. Confirm the evidence and context before drawing a consequential conclusion.
Compare the submitted metric with its agreed definition, period and expected range, then show the source and discrepancy to a reviewer. Check changes in population or reporting method before treating the value as an issue. An unexpected metric alone is not evidence of fraud.
When the agreed review or corrective step is completed and recorded, or the evidence shows the trigger was invalid. Acknowledging the message alone is not resolution.
Review useful alerts, false alarms, missed issues and response time against a defined purpose. Test revised rules and monitor whether they lead to appropriate action, not just more notifications.
Next: ask questions across the portfolio evidence. Bring the reviewed issues, source references and unresolved uncertainties.
Bring one monitoring concern, its source evidence and your response rule. Work through the alert and review workflow with Sopact.
Explore Impact & ESG Portfolio →
