CASE STUDY · HEALTHCARE & LIFE SCIENCES · WORKFLOW AUTOMATION

Two Web Apps Replace Paper Requests and Manual Goal Tracking for a Senior Living Nonprofit

A SharePoint form now routes every marketing request, and a cascading .NET and Angular application tracks goals across the organization.
Businesswoman working on laptop with quarterly progress chart in background.

The Enterprise Challenge

Marketing requests and goal updates moved on paper, often lost, with no visibility into where a request stood.

The client is a nonprofit senior living organization, the driving force behind three not-for-profit Life Plan communities in the mid-Atlantic region. Its marketing department handled image and graphic requests on paper. That approach led to frequent lost requests and a lack of visibility into the status of each request, and the reliance on paper and verbal communication created bottlenecks that hindered the efficiency of the workflow, making it difficult for the marketing team to manage and track their tasks effectively. A request that exists only as paper on someone’s desk carries no status anyone else can read.

The organization also struggled with tracking and measuring progress toward quarterly goals. The absence of a structured tracking system meant that departmental progress was only discussed informally during meetings, leaving team members in the dark about their achievements. That was not only a reporting gap. Merit-based compensation was tied directly to those goals, so the inability to measure progress effectively created complications in evaluating and rewarding performance fairly.

The Solution

At a Glance

A senior living nonprofit’s marketing requests and organizational goal tracking moved on paper, often losing visibility into where a request stood. i3solutions built two web applications, one routing marketing requests and one tracking goals, to replace the paper trail.

Marketing image and graphic requests once handled on paper and frequently lost now flow through one standardized online entry form held in SharePoint, and a process with no visibility into request status now gives queue tracking that shows who completed each step and when.

Screenshot of the resident request and goal-tracking web application

Strategic Trigger

Pay Was Tied to Numbers Nobody Could Produce

Most manual-process problems cost an organization time. This one also decided compensation. Bonuses were tied directly to quarterly goals, and the only record of progress toward those goals was what got said in a meeting. When the measure of performance lives in recollection rather than in a system, evaluating and rewarding performance fairly stops being a management preference and becomes a problem the organization cannot solve with more diligence.

The marketing workflow had the same shape from the other direction. Requests moved on paper and by word of mouth, so the only people who knew where a request stood were the people who had touched it, and when the paper went missing the request went with it. Both workflows were missing the same thing: a record that outlives the conversation. What the engagement put in their place was not tighter follow-up but two applications that keep the record themselves.

Conditions That Triggered the Engagement

  • Image and graphic requests handled on paper in the marketing department, with requests frequently lost and no visibility into the status of any given request
  • Quarterly goal progress discussed informally in meetings, with no structured tracking system recording it
  • Merit-based compensation tied directly to goals the organization had no reliable way to measure

Two Problems Wearing the Same Clothes

This organization’s marketing requests and goal tracking looked like separate problems, but both were paper artifacts that held no state. If two workflows in your organization share that same underlying issue, one system can often solve both.

Stakes

Two Workflows With No Record Behind Them

Left on paper, the marketing workflow keeps producing the same three failures: requests get lost, nobody can say what stage a surviving request is at, and the bottlenecks created by paper and verbal communication go on hindering the efficiency of the workflow. Each of those is recoverable on its own. Together they make it difficult for the marketing team to manage and track their tasks at all, which is a capacity problem, not a tidiness problem.

The goal-tracking side carries the sharper risk, because the consequence is not delay but fairness. With departmental progress discussed only informally during meetings, team members are left in the dark about their achievements, and the organization has no accurate way to assess goal attainment. With merit-based compensation tied directly to those goals, every compensation decision rests on a record the organization does not actually hold.

Constraints and Complexity

Two Different Workflows, One Standardization Problem

The two problems looked unrelated and were not. An image and graphic request is a short-lived item that moves through several hands; a quarterly goal is a long-lived item that flows down an organization and then has to roll back up. What they shared was that both ran on artifacts, paper forms and manual spreadsheets, that hold no state and report nothing. Solving them separately would have produced two more places for work to hide, so both had to be assessed and mapped before either was built.

The second constraint was who the users are. Requesters, marketing staff, team leaders, managers, and individual contributors all touch these applications, and each of them touches them for a different reason: submitting a request, moving one through a queue, setting a goal, aligning to one, or reporting on progress against it. That put two requirements on the design ahead of any technology choice: one standardized entry point so a request cannot be submitted in a shape the queue does not understand, and permission structures that limit who can submit and edit requests, so standardization does not come at the cost of control over the marketing record.

Selection Rationale

Senior Microsoft Specialists with Proven Delivery Depth

The requirements defined the vendor profile. This was not a product configuration job: it needed a team that could assess and map two live business workflows first, then build custom web applications against the maps, with the request form built directly in SharePoint and permission structures enforced inside it, and a back end capable of cascading goals down an organization and rolling reports back up. Both applications also had to arrive as working systems, because the only thing to fall back on was the paper and the spreadsheets the engagement existed to retire.

The organization engaged i3solutions, a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, delivered by an all-senior, all US-based delivery team. That profile matched the work: senior engineers who have built SharePoint-based request systems and custom .NET applications repeatedly, and who could do the Business Process Management analysis and the build with the same team rather than handing a process map to someone else to implement.

The Engagement Approach

i3solutions ran a detailed assessment of both workflows, mapped them, and used Business Process Management to replace them with two tracked web applications: a Marketing Request Application and a goal tracking application.

PHASE 01

Workflow Assessment and Process Mapping

i3solutions conducted a detailed assessment to identify the inefficiencies and bottlenecks in the organization’s manual processes, then crafted detailed process maps and wireframe diagrams to visualize and plan the new workflows. The team collaborated continuously with the organization’s own people so the design matched how the work actually ran, not how it was assumed to run.

PHASE 02

Marketing Request Application

The core of the solution is one standardized Marketing Request entry form, an online platform for submitting requests for images and graphics. The form is built directly in SharePoint, which holds the requests and, through permission structures, limits who can submit and edit them. The full lifecycle of a request, from submission to completion, moves through queues.

Implementation phases for this engagement: Phase 01, Workflow Assessment and Process Mapping; Phase 02, Marketing Request Application; Phase 03, Goal Tracking Application; Phase 04, Retiring the Spreadsheets and Paper Forms.

PHASE 03

Goal Tracking Application

Goals originate with team leaders and cascade down to managers and individuals, who align their own objectives accordingly. The application rolls that data back up into management reports, team status reports, and individual progress tracking, so departmental progress is recorded rather than described.

PHASE 04

Retiring the Spreadsheets and Paper Forms

Both applications took the place of the manual spreadsheets and paper forms they were built to replace. Automated email notifications over SMTP took over the status updates that had previously travelled by paper and conversation, so stakeholders learn where a request or a goal stands without asking.

Technical Transformation

The two applications share a stack and split the work. SharePoint is the collaborative platform the applications are built on and the secure repository for marketing requests: the image and graphics request form is built directly in SharePoint, and its permission structures decide who can submit and edit a request. Behind the interface, .NET carries the back-end logic, including integration, user authentication, and data handling, organized under an MVC architecture that separates data handling, user interface, and application logic so both applications stay maintainable and can be extended without a rewrite. The interface layer is Angular with Kendo UI for interactive components, grids, and charts; jQuery and JavaScript for dynamic content updates, form validations, and real-time status tracking; and Bootstrap with CSS for a responsive, consistently branded layout across devices. Raven DB, a NoSQL document-oriented database, stores the data for both marketing requests and organizational goals, which is what lets two differently shaped records live in one system. SMTP sends the automated status notifications about request status and goal progress, which is the piece that replaces the verbal handoff.

Before and after diagram: paper marketing requests and manually tracked goals, replaced by two SharePoint-based web apps with full status visibility.

Measurable Outcomes

Requests Tracked, Status Visible

A standardized SharePoint request form and a cascading goal tracking application replaced paper and verbal communication with an enforced, visible process.


Outcome Before After
Marketing image and graphic requests Handled on paper, frequently lost One standardized online entry form held in SharePoint
Request status visibility No visibility into the status of any given request Queue tracking showing who completed each step and when
Who can submit and edit requests Paper forms and verbal communication, no enforced control SharePoint permission structures limiting submission and editing
Quarterly goal tracking Discussed informally in meetings Goals cascade from team leaders to managers and individuals in a tracked application
Goal reporting No structured tracking system behind merit-based compensation Management roll-up reports, team status reports, and individual progress tracking
Status communication Paper and verbal handoffs Automated SMTP email notifications on request status and goal progress

What changed here changed in kind rather than by a percentage. The transition to automated systems reduces the time spent on manual data entry and tracking, which the organization frames as faster processing of requests and tasks. Replacing manual spreadsheets and paper forms with the two applications minimizes the risk of errors associated with manual data handling, so goal tracking and request management are more reliable. And a request in a queue cannot be lost the way a paper form and a verbal handoff could.

The second change is visibility, and it runs in both directions. The new systems provide reporting and real-time visibility into progress and performance, which keeps senior leadership informed of key metrics and project statuses and gives them something to decide from. Users get the same benefit at their own scale: being able to see and track their own goals boosts accountability, motivation, and personal engagement with their objectives. With centralized and automated processes and automated notifications carrying status, communication about requests and goals no longer depends on someone remembering to pass it along, which reduces delays and miscommunication between teams and with senior leadership.

Decorative quotation mark.

PENDING-CLIENT-QUOTE

Who This Engagement Serves

This engagement is relevant for

  • A marketing or creative team taking work requests on paper or by email, where requests go missing and no one can say what stage a request is at
  • An organization whose goal tracking lives in meeting discussion while compensation decisions depend on it
  • A team ready to have its actual workflows assessed and mapped before anything is built, rather than buying a tool and fitting the process to it

Less relevant for

  • Your request intake and goal tracking already run in a system of record that reports status without anyone being asked
  • Your request volume is low enough that a single shared list still works and nothing downstream depends on the record

What This Engagement Established

Two Paper Workflows, Replaced by Two Applications That Keep Their Own Record

The engagement established that the marketing request problem and the goal tracking problem were the same problem wearing different clothes: work moving on artifacts that hold no state. Business Process Management was applied to both, starting with a detailed assessment and process maps of how each workflow actually ran.

What replaced them is one standardized Marketing Request entry form built directly in SharePoint, with permission structures over who can submit and edit and queues that show who completed each step and when, and a goal tracking application in which goals cascade from team leaders to managers and individuals and roll back up into management reports, team status reports, and individual progress tracking. Both applications took the place of manual spreadsheets and paper forms, and the record they keep is the thing the paper never could.

Frequently Asked Questions

Yes, that was the approach here. Before building anything, this senior living nonprofit’s marketing request and goal tracking workflows were assessed and mapped as they actually worked, which is why the two resulting web applications replaced paper requests and meeting-based goal discussions with full status visibility, rather than forcing existing work into an off-the-shelf tool. If you want the process understood before the build starts, that’s the same starting point.

By mapping the workflow before building anything against it. On this engagement, i3solutions began with a detailed assessment to identify the inefficiencies and bottlenecks within the organization’s manual processes, then produced detailed process maps and wireframe diagrams to visualize and plan the new workflows, collaborating continuously with the organization’s team so the result matched its specific needs. Business Process Management is the frame: the goal is standardized, automated operations, not a digital copy of the paper form. Both of the organization’s manual workflows, marketing image and graphic requests and quarterly goal tracking, went through that same sequence, which is why the two applications share a stack and a set of conventions instead of becoming two separate tools with two separate ways of recording status.

Through one standardized Marketing Request entry form, an online platform for submitting image and graphic requests. The entire lifecycle of a request, from submission to completion, is tracked through queues, and users can monitor progress and see who completed each step and when. The form is built directly in SharePoint, which serves as the secure repository for the requests, and permission structures mean only authorized users can submit and edit them. Status does not depend on anyone relaying it: SMTP-based automated email notifications tell stakeholders where a request stands. The interface around the queue is Angular with Kendo UI, jQuery and JavaScript, and Bootstrap with CSS, with .NET handling the back-end logic under an MVC architecture and Raven DB storing the records.

Goals originate with team leaders and cascade down to individuals or managers, who align their own objectives accordingly. The application offers roll-up reports for management, team status reports, and individual progress tracking, so departmental progress is recorded instead of discussed informally during meetings. That record matters because bonuses are tied directly to these goals. The reporting works in both directions for a reason: leadership needs the roll-up to stay informed of key metrics and project statuses, and individuals need to see and track their own goals, which supports accountability, motivation, and personal engagement with their objectives. Because the same platform holds both the goals and the progress against them, evaluating goal attainment reads from one record rather than from a set of recollections.

Manual spreadsheets and paper forms in the marketing department, and the informal meeting discussion that stood in for quarterly goal tracking. Both now run through the applications, which makes requests and tracking uniform: a queue cannot lose a request the way a paper form and a verbal handoff could, and it does not leave anyone guessing about status. Replacing the manual artifacts also removes the error class that came with them, since data is entered once into a structured application rather than re-keyed across spreadsheets, which makes goal tracking and request management more reliable. The organization’s own summary of the change is that the applications ensure uniformity in requests and tracking and eliminate the errors and delays associated with manual methods.

SharePoint is the collaborative platform the applications are built on and the repository for marketing requests. .NET powers back-end development, including integration, user authentication, and data handling, organized under an MVC architecture that separates data handling, user interface, and application logic. Angular, Kendo UI, jQuery and JavaScript, and Bootstrap with CSS build the responsive interface, including grids and charts. Raven DB, a NoSQL document-oriented database, stores the data, and SMTP sends the automated email notifications about request status and goal progress. The division of labor is the point: SharePoint provides the collaborative platform, the repository, and the permission structures, and the custom development went into the request queues, the goal cascade, and the roll-up reporting on top of them.

i3solutions is a Microsoft Partner with 30 years of delivery experience and 1,500+ Microsoft engagements, with every engagement staffed by an all-senior, all US-based delivery team. This engagement shows what that profile buys on a Business Process Management job: the same senior team ran the workflow assessment, produced the process maps and wireframes, and then built both applications against them, so nothing was lost between analysis and implementation. The work spans SharePoint permission structures, .NET under MVC, an Angular and Kendo UI interface, Raven DB storage, and SMTP notifications, which is a wider stack than a single-product specialist covers. For organizations weighing similar work, a short scoping conversation establishes what the equivalent build would take in your environment.

Related Insights

More From i3solutions

A Record the Paper Never Could Keep

Both applications here replaced manual spreadsheets and forms with something that actually tracks status and history. We’re glad to discuss what a comparable pair of workflow fixes would look like for your organization.