I used AI to anticipate the questions this panel might ask — and answered each one in full. If your question isn't here, I'm happy to answer it directly.
Kevin Brown — Contractor, EBU. This page was compiled using AI to systematically work through the MTN AI & Automation Forum feasibility template and generate answers specific to SR Logger. Every answer here reflects the actual submitted feasibility document. I'm presenting this to demonstrate both the rigour of the preparation and the kind of AI-assisted workflow that this project enables.
Approximately 15 minutes per SR. That covers reading the email, identifying the BOM PDF from the attachments, opening it, and manually transcribing 14 structured fields into the SR_Master sheet on SharePoint. Every field is typed by hand — no copy-paste possible from a PDF in this workflow.
Daily, continuously. The ICT COM Support mailbox receives 6 to 15 qualifying SR emails every working day. SRs arrive throughout the day — it's not a batch process. The automation's 15-minute polling schedule mirrors the continuous nature of the inflow.
6 to 15 SRs per day on average — passes only, not counting fails filtered during pre-screening. Daily, Monday to Friday. Month-end is the peak period when volumes trend toward the upper end of that range.
Month-end. EBU deal volumes peak at month-end, driving higher SR submission rates. The 15-minute polling schedule handles this naturally — Power Automate queues and processes SRs sequentially without any configuration changes at peak.
Target AHT post-automation: 1 minute — the review time for AI Builder flagging a low-confidence extraction. Currently 15 minutes manual. If AHT isn't met: delayed order fulfilment, TAT and SLA misses, and negative brand impact for EBU accounts awaiting service delivery.
Yes. Power Automate's O365 Outlook connector handles mailbox polling. The SharePoint connector handles writing rows to SR_Master. AI Builder provides the document processing API for BOM extraction. Microsoft Graph API is available as a fallback for finer-grained mailbox access if needed.
Currently: Outlook (SR emails + BOM PDFs) and Excel via SharePoint (SR_Master workbook). Post-automation: Power Automate as orchestrator, AI Builder for PDF extraction, SharePoint as destination. Same systems — we're automating the human steps between them.
Extremely stable. The solution runs entirely within Office 365 — Outlook, SharePoint, Power Automate, AI Builder. All Microsoft-managed. No custom on-prem systems in the loop. No known changes planned to any of these platforms that would affect the solution.
Yes — Office 365 MFA via Microsoft Authenticator under the MTN tenant. The Power Automate flow runs under a service account authenticated through the O365 tenant — covered by the same MFA policy. No special bypass required.
Three: Power Automate (orchestrator), Outlook (mailbox), SharePoint (SR_Master). AI Builder runs embedded within Power Automate — not a separate application access.
Two main challenges. First, BOM field extraction variability — 14 structured fields from PDFs where layout can differ across BOM versions. AI Builder's document processing model handles this better than simple text extraction. Second, the DLP policy restricting Power Automate's connector access to the shared mailbox — already escalated to Donovan Burgess for allowlisting. Known blocker, not a surprise.
No formal contractual SLA for the logging step itself, but the de facto SLA is the TAT — currently 15 minutes per SR from receipt to logged. The automation targets 1 minute. Downstream, SRs feed into the order processing pipeline which carries customer-facing SLAs, so logging delays have a real knock-on effect on delivery commitments.
No direct financial penalties for the logging step. But the consequence is a downstream order processing backlog — the fulfilment team can't action SRs that aren't logged. This rolls into customer delivery delays and potential SLA breaches on the customer-facing side. Indirect cost: 33–82 consultant hours per month on admin instead of value-add work.
No. SR emails arrive during business hours aligned to the EBU sales cycle. The 15-minute polling schedule covers the full business day. No overnight or weekend processing required for MVP 1. If that changes, Power Automate can be reconfigured — the schedule is just a parameter, no architectural changes needed.
Directly: order processing backlog grows. Each unlogged SR sits in a queue the fulfilment team can't see or action. Indirectly: consultant time that should clear the backlog is consumed by manual logging. Compounded: 33–82 hours of lost productivity per month — conservative estimate based on 6–15 SRs at 15 minutes each across 22 working days.
The system uses a confidence threshold. If AI Builder is less than 90% sure about a field, it does not log the entry automatically. Instead, it triggers a consultant review notification. We prioritize data integrity over 100% automation.
This is a Citizen Developer model. By using tools MTN already pays for, we are reclaiming 30–77 hours of productivity immediately without waiting in a long-term development queue. It is about solving the pain point today.
The data never leaves the MTN Microsoft 365 tenant. We are using standard O365 connectors, meaning the security and privacy posture remains identical to the current manual process, just more auditable.
Yes. Three alternatives evaluated: Python scripting — requires a dedicated machine running continuously, no audit trail in the MTN environment, not maintainable without a developer. VBA macros — can't reliably access Outlook or read PDFs. Dedicated RPA tool (UiPath) — no existing licences, introduces a new platform. Power Automate + AI Builder was selected: already in our O365 tenant, fully auditable, citizen-developer maintainable, zero additional spend.
Yes — it's the first step in the SR lifecycle. After logging: pre-screening, allocation, fulfilment, billing. MVP 1 automates logging only, but creates the clean, structured data foundation that makes MVP 2 — automated pre-screening and allocation — possible. Without reliable SR_Master data, you can't build intelligence on top of it.
Multiple. MVP 1: eliminates manual transcription entirely — 14 minutes saved per SR, zero transcription errors, real-time logging. MVP 2: extends to pre-screening and allocation, removing two more manual steps. Long-term: structured SR_Master data enables reporting, SLA tracking, and workload analytics that aren't feasible today.
For MVP 1: one key notification — if AI Builder's confidence score falls below threshold, an alert fires to the consultant for manual review. Every automated log is timestamped and traceable in SR_Master (audit trail). Formal acknowledgement emails or summary reports to stakeholders are not in MVP 1 scope — natural MVP 2 addition.
Yes. SR_Master on SharePoint is the master record for all ICT COM Support service requests. The automation writes directly to it. A duplicate guard is built in — before writing any row, the flow checks whether that SR number already exists. If it does, it skips. Every row written is timestamped for a full audit trail. Two-layer protection: subject-line prefix filter + SR number deduplication check.
14 fields from the BOM PDF: SR #, Customer Account Number, Customer Name, Assigned consultant, Request Detail, Order Type, Date in Siebel, Requested Date, Week, Requestor Name, Priority / Bulk Sites, Currency, SOF MRC, SOF NRC. These map directly to existing SR_Master columns — no schema changes required.
Same data, transformed format: from semi-structured PDF (source) to a structured Excel table row (destination). AI Builder handles the transformation. No manual manipulation in the automated path — the only human touchpoint is a review step when AI Builder flags low confidence on an extraction.
No direct legal impact. Data processed is internal MTN business data — SR references, customer account numbers, order details. Stays within the MTN Office 365 tenant. No PII processing triggers POPIA obligations beyond what the current manual process already handles.
Three primary KPIs: (1) TAT per SR — 15 min to 1 min, a 93% reduction, measured by SR_Master timestamps vs email arrival times. (2) Monthly consultant hours reclaimed — target 30–77 hrs, measured by SR volume × time saved. (3) Data accuracy — target 0% transcription errors, verifiable during the two-week UAT parallel run. Reported to Ismut Paruk monthly for Q1 post-go-live.
No additional budget required. Power Automate, AI Builder, SharePoint, and Outlook are all in our existing Microsoft 365 licensing — MTN already pays for these. AI Builder credits are included in the Power Apps per-user plan. No third-party tools, no new infrastructure, no additional licences. The only resource cost is my time as contractor, within current scope.
Long-term. MVP 1 is a permanent replacement for manual logging, not a workaround. Designed to scale — the same flow handles increased SR volumes without changes. MVP 2 extends it, doesn't replace it.
The ICT COM Support consultant team — not a dedicated role but a task distributed across every consultant on duty. That's part of why the time cost is significant: it's a shared overhead across the whole team, not one person's problem.
Currently at Idea/POC stage. The existing SOPs for the manual process sit with the ICT COM Support team — Natalie Dunn (Manager ICT) can provide those. Ismut Paruk (Senior Manager BPO) holds the broader process context. The Power Automate flow itself becomes the documented process artefact once built.
Both. Internal: ICT COM Support consultants, Ismut Paruk, Natalie Dunn, downstream fulfilment and account management teams. External: EBU customers and their account managers who submit SR requests — they send the emails that trigger the entire process.
Four downstream impacts: Capacity reclamation — 33–77 hrs/month freed. Backlog reduction — fulfilment team gets faster, cleaner data. Standardisation — every SR_Master row structured identically, enabling future analytics. Traceability — timestamped audit trail that doesn't exist in the manual process today.
Three things. (1) MVP 1 is deliberately scoped to logging — deliver value fast, prove the pattern, then expand. MVP 2 adds pre-screening and allocation. (2) DLP policy is the one technical blocker — escalated to Donovan Burgess, the single decision needed today. (3) Citizen Developer model — no IS team dependency, no project queue. I start building the moment the DLP is unblocked.