Overview

This is the story of a project that grew over about six months from a single Microsoft Form into a fully automated, AI-assisted request management system. Each phase was a direct response to whatever bottleneck was causing the most pain at the time: no intake point, then a manual tracker, then an unreliable board, then no reporting, then no way to catch duplicate work before it started or have visibility into related requests. The result was a complete transformation of how the team handled incoming requests.

The problem

I work with a marketing services team that supports several different product marketing teams at a large software/technology enterprise. Previously, requests came to us however people happened to reach us — Teams messages, email, phone calls, hallway conversations. There was no single intake point, which meant no way to track, no reporting on volume or request type, and no shared visibility into what was outstanding or who owned what.

The impact went both directions. Requesters didn't have a clear, consistent way to ask for help or know what happened after they did. The team had no way to see the full picture of demand, so fulfillment was slow and inconsistent — not because the work wasn't getting done, but because nothing showed what was in flight, what was overdue, or who was carrying what load.

Triage for these requests belonged to the PM assigned to field requests and to the team's director, who was under pressure from leadership to drive efficiency and automation across the group. I was pulled in because I was the most technically capable person on a team made up mostly of PMs and marketers.

The project turned into roughly six months of incremental automation work, done alongside my regular responsibilities rather than as a dedicated project.

Phase 1: A single intake point

The team decided the first fix had to be a single required entry point, and I was asked to help build it. We created a Microsoft Form and iterated on the questions and format together — the goal was to capture enough detail on each request (especially request type) to route it correctly, since fulfillment was spread across roughly eight people depending on what was being asked for.

The form solved intake chaos, but form data doesn't manage itself — submissions just landed in a raw Excel export. The team still had no tracking, no ownership model, and no reporting.

Phase 2: Manual process reveals the next bottleneck

The PM assigned to field incoming requests built a process around that export: copy-paste each new submission into an Excel tracker that mirrored the form fields, then separately build a formatted "request profile" in OneNote to share over Teams so the right person could pick it up. It worked, but it meant entering the same request twice by hand, and it didn't scale as more people found out about the form and volume grew.

My first automation closed that gap: a Power Automate flow that pushed each form submission directly into the Excel tracker, eliminating the copy-paste step entirely.

Impact: roughly 10 minutes saved per request at an average of 5 requests/week — about 40+ minutes a week back for the PM, with zero risk of transcription errors between the form and the tracker.

Efficiency had become a real priority for the team by this point, and this small win built the case for going further.

Phase 3: From spreadsheet to Planner

The team wanted more than a tracker — they wanted to actively manage each request as its own trackable unit of work, and landed on Microsoft Planner for its visual board and built-in project management features. But manually creating a Planner card for every request would have added effort right as volume was increasing, and in practice the PM's manual Planner updates fell chronically behind. The board wasn't trustworthy, so people stopped relying on it, and the original visibility and satisfaction problems persisted despite the phase 2 win.

I researched and tested a working architecture to automate Microsoft Forms directly into Planner, then built a Power Automate flow that creates a Planner card for every new request the moment it's submitted. That single flow made both the Excel tracker and the OneNote request-profile step unnecessary — one automated source of truth replaced two manual ones.

Impact: on top of the phase 2 savings, this saved roughly another 20 minutes per request — about 1.5 hours a week combined — but the bigger win was qualitative. The team got real-time visibility into every request's status, meaningfully better reporting, and a level of project tracking it hadn't had before. It mattered organizationally too: the director had a top-down mandate to drive efficiency and automation, and this program became one of the clearest examples of that mandate actually delivering.

Phase 4: Turning request data into a reporting layer

With intake and tracking automated, the next ask was reporting — the team had a growing, well-structured database of requests for the first time, and wanted to actually use it. I built a Power BI dashboard connected directly to Planner via API, giving real-time visibility into the full set of active and archived requests rather than a point-in-time export.

The dashboard let the team slice the data however they needed: request volume over time, breakdown by request type, requesting team, individual requestor, and tags we'd added to track whether a request was tied to a specific event, feature release, or campaign.

The most useful cut wasn't one anyone had explicitly asked for. Because I had access to both a request's original form submission and its current state in Planner, I could track how often the triage PM re-assigned a request's type after talking to the requestor — a proxy for how well people actually understood the form and the program itself. That turned the dashboard from a status report into a feedback loop: it showed not just what was happening, but where the intake process itself was still confusing people.

Phase 5: AI-assisted triage

The team had talked about wanting AI to help with request management — surfacing similar past requests, spotting connections between requests, and avoiding duplicated effort. So I set about implementing an AI-assisted triage flow within the existing workflow that automatically analyzes every new request and compares it against the full history of requests in the SharePoint index.

The intake workflow already created a Planner card for every new request. I added a step that also wrote a row into a SharePoint list acting as a running index of every request, and set that index to refresh daily against Planner so it stayed current with any status changes on existing requests. A new AI analysis flow then triggers on every new request: it builds a profile of the incoming request and uses a curated prompt through the OpenAI GPT connector to compare it against the SharePoint index, returning up to five likely matches based on request type, requestor, requesting team, and keyword similarity in the description.

That analysis, along with a link to the new request's Planner card and links to each matched card, gets sent straight to the triage PM. Previously, their first touch point with a new request was the generic Forms submission notification, then a manual trip to the Planner board to find it. Now they open the request already knowing what it might relate to, with one click to everything relevant.

The exact time savings here are hard to isolate, but the qualitative shift is real: triage starts with context instead of a blank slate, and duplicate or overlapping work is far less likely to slip through.

Where it stands today

Request volume has kept increasing since the system went live, and the SharePoint index now holds a full year's worth of structured request data — data the team didn't have before at all. Beyond running the day-to-day workflow, that history has become a resource in its own right: something the program can analyze on its own terms to understand its work and inform how it evolves.

Results

• ~3+ hours a week of manual work eliminated from the PM's tracking and triage process, combining the direct time savings from phases 2 and 3 with a conservative estimate of the added efficiency from phase 5's AI-assisted triage.
• Two manual, duplicative systems retired (the Excel tracker and the OneNote request profile) and replaced with one automated source of truth.
• Real-time reporting the team never had before — request volume, type, requestor, and campaign/event tracking, plus a proxy metric for how well the intake form itself was understood, drawn from how often triage reclassified a request's type.
• AI-assisted triage that surfaces likely duplicate or related requests automatically, rather than relying on any one person's memory of what had come through before.
• A year of structured program data that didn't exist previously, now available for the team to evaluate its own performance and plan ahead.
• Delivered on a leadership mandate — the director had a top-down directive to drive efficiency and automation, and this became one of the clearest examples of it working.