diff --git a/Meeting Brief - SR Automation.md b/Meeting Brief - SR Automation.md
new file mode 100644
index 0000000..f5148a8
--- /dev/null
+++ b/Meeting Brief - SR Automation.md	
@@ -0,0 +1,86 @@
+# SR Automation — Meeting Brief
+
+## What is this tool?
+
+SR Automation is an Excel VBA macro running on a Windows VM. It is used by the Argentina team to process monthly subscriber reports from ~80 Polish cable/IPTV operators for Disney.
+
+**How it works today:**
+1. Polish operators send their monthly subscriber data via email (Excel/ODS/PDF attachment, subject: `RAPORTY`)
+2. The macro connects to a generic Outlook mailbox, downloads attachments, and parses the data
+3. Parsed data is compared against the Disney AIS historical data to detect discrepancies
+4. Output files are generated per operator and saved locally
+5. **Manual step:** results are uploaded to Disney's AIS system by a team member (Disney has not agreed to direct API write access — this step stays)
+
+---
+
+## Known Issues
+
+### Tool / Technical Bugs
+
+| # | Issue | Impact |
+|---|---|---|
+| 1 | Macro skips items during processing | Missing data in output, requires re-run |
+| 2 | No crash recovery — re-running after a crash produces corrupted output | Team must know to close and reopen the file; if they re-run without doing so, garbage data is generated |
+| 5 | Two clients sharing one email address — identification logic fails | Incorrect subscriber values assigned to wrong operator |
+
+### Configuration & Process (Human Error)
+
+| # | Issue | Impact |
+|---|---|---|
+| 3 | Mapping is maintained manually in an Excel sheet — additions, deletions, misconfigurations happen; some contracts have non-standard rules (e.g. client billed for only 80% of subscribers) | Wrong output values, requires manual correction |
+| 6 | Team selects wrong reporting period | Entire run processes wrong month |
+
+### Client Behavior (Outside Tool's Control)
+
+| # | Issue | Impact |
+|---|---|---|
+| 7 | Some clients return the Excel template filled in as a scanned image or PDF instead of the original Excel file | Cannot be parsed automatically; requires manual handling |
+
+### Already Resolved
+- Rounding errors — fixed in current version
+
+---
+
+## VM Performance Problem
+
+The macro runs on an Azure Virtual Desktop. Processing time for the **same dataset** varies significantly:
+- Normal: ~10–15 minutes
+- Bad days: 1–2 hours
+
+The root cause is VM-level (Azure resource contention, CPU throttling) — not the macro logic itself. This has been getting worse over recent months and is the most visible pain point for the Argentina team.
+
+**This cannot be reliably fixed within the current Excel/VM architecture.**
+
+---
+
+## Future Vision
+
+Replace the Excel VBA macro + VM with a background service. The Argentina team would see ready data at the end of the month — no manual import, no waiting.
+
+**Proposed stack:**
+- **n8n** — workflow automation platform to orchestrate the end-to-end pipeline
+- **Database** — store monthly extracts persistently; enables month-over-month history and audit trail
+- **Microsoft Graph API** — connect to generic mailboxes via API, replacing the Outlook COM dependency
+
+**What this solves:**
+| Current problem | How new architecture addresses it |
+|---|---|
+| VM performance unpredictable | Service runs in cloud, no VM dependency |
+| Re-run after crash corrupts data | Database-backed processing is idempotent — safe to re-run |
+| Manual mapping in Excel prone to errors | Mapping stored in database, manageable via UI |
+| Team selects wrong reporting period | Period auto-detected from email date |
+| No history between months | Database retains all extracts by period |
+
+**What stays the same:**
+- Manual upload to Disney AIS (Disney requirement — no direct API access)
+- Client-side issue with PDF/image submissions (process enforcement needed on operator side)
+
+---
+
+## Open Questions for This Meeting
+
+1. **RPA vs n8n** — Argentina team was exploring RPA as an alternative. How does that align with the n8n direction? Is there a preference or constraint on tooling?
+2. **Ownership model** — Jan has the domain knowledge; transformation team has the engineering capacity. What does collaboration look like?
+3. **MVP scope** — what must work in v1 to replace the current tool for the Argentina team?
+4. **Timeline** — when can the team realistically start? Are there dependencies (Azure AD app registration for Microsoft Graph, infrastructure provisioning)?
+5. **Quick wins** — are there issues from the list above that can be patched in the current tool while the new service is being built?