A single green tree stands in a bright golden, shimmering field with a vibrant blue river and blue sky overhead

Governing Change Requests at Scale

Turning scope disputes into auditable decisions and unlocking $100K+ in approved revenue across complex B2C app builds.

See Solution

Governing Change Requests at Scale

Turning scope disputes into auditable decisions and unlocking $100K+ in approved revenue across complex B2C app builds.

See Solution

Initial assumptions

We initially treated change requests as a workflow problem - assuming better ticket structure and familiar patterns would reduce friction.

In reality, the breakdown wasn’t in how requests moved forward, but in how decisions were documented, traced, and defended. Conversations lived across Basecamp threads, texts, and emails, with no reliable system of record for scope, approvals, or pricing.

This made it clear that improving the flow alone wouldn’t fix the problem. What was missing was governance.

Modern home office setup with a monitor, ergonomic chair, keyboard, and indoor plants near a window with blinds.

The research made one thing clear: scope couldn’t be clarified by better conversations - it needed to be evaluated against evidence.

This led to an AI-assisted scope analysis model that reads the approved BRS alongside each change request, surfaces relevant context, and supports faster, more confident decisions , without removing human judgment.

Overview

I designed an internal change request platform that replaced ad-hoc conversations with a governed, end-to-end workflow.

The system gave teams a single source of truth to classify scope, explain pricing, capture approvals, and track decisions over time - reducing disputes, speeding reviews, and helping the business scale post-launch change with confidence.

Role

I owned the end-to-end design of the change request platform, defining the system-level structure that governed scope, approvals, and history at scale.

Research, AI-Protyping

Timeline

2 months

<3 min

Time spent finding context per change request

<3 min

Time spent finding context per change request

~30%

Quote pushback through clearer scope visibility

~30%

Quote pushback through clearer scope visibility

↑ 85%

Approval rate with traceable, in-platform approvals

↑ 85%

Approval rate with traceable, in-platform approvals

Designing change requests the way Humans and AI collaborate

Designing change requests the way
Humans and AI collaborate

At scale, change requests stop being exceptions and become the workflow.

At Appsketiers, most clients requested changes after launch. But those requests lived across Basecamp threads, texts, and emails with no clear ownership, traceability, or system of record. This friction didn’t just slow work - it eroded trust and revenue.

At Appsketiers, most clients requested changes after launch. But those requests lived across Basecamp threads, texts, and emails with no clear ownership, traceability, or system of record.

This friction didn’t just slow work - it eroded trust and revenue.

Designing change requests the way Humans and AI collaborate

At scale, change requests stop being exceptions and become the workflow.

This friction didn’t just slow work - it eroded trust and revenue.

At Appsketiers, most clients requested changes after launch. But those requests lived across Basecamp threads, texts, and emails with no clear ownership, traceability, or system of record.

This friction didn’t just slow work - it eroded trust and revenue.

Overview

I designed an internal change request platform that replaced ad-hoc conversations with a governed, end-to-end workflow.

Role

I owned the end-to-end design of the change request platform, defining the system-level structure that governed scope, approvals, and history at scale.

Research, AI-Protyping

Timeline

2 months

<3 min

Time spent finding context per change request

~30%

Quote pushback through clearer scope visibility

↑ 85%

Approval rate with traceable, in-platform approvals

Initial assumptions

We initially treated change requests as a workflow problem - assuming better ticket structure and familiar patterns would reduce friction.

This made it clear that improving the flow alone wouldn’t fix the problem. What was missing was governance.

⏱️ Change Became the System

Through interviews with 3 internal developers, business analysts, and multiple clients, we found that nearly 90% of clients returned with post-launch changes. Those requests lived across Basecamp threads, texts, and emails. Scope decisions were buried in conversations, approvals could be deleted, and teams spent 20–30 minutes per request just reconstructing context.

Repeated disputes over what was in or out of scope

Late discoveries around feasibility and cost

Heavy dependency on developers for early scoping

The research made one thing clear: scope couldn’t be clarified by better conversations - it needed to be evaluated against evidence.

Initial assumptions

We initially treated change requests as a workflow problem - assuming better ticket structure and familiar patterns would reduce friction.

The research made one thing clear: scope couldn’t be clarified by better conversations - it needed to be evaluated against evidence.

Overview

I designed an internal change request platform that replaced ad-hoc conversations with a governed, end-to-end workflow.

Role

I owned the end-to-end design of the change request platform, defining the system-level structure that governed scope, approvals, and history at scale.

Research, AI-Protyping

Timeline

2 months

<3 min

Time spent finding context per change request

<3 min

Time spent finding context per change request

~30%

Quote pushback through clearer scope visibility

~30%

Quote pushback through clearer scope visibility

↑ 85%

Approval rate with traceable, in-platform approvals

↑ 85%

Approval rate with traceable, in-platform approvals

How change requests really move

Before designing, I partnered with two product managers to map real change-request workflows across 8+ client engagements.

This work focused on observing how scope decisions were made in practice, who was involved, where handoffs broke, and how approvals actually happened - grounding the system design in real operating constraints.

AI-assisted scope decisions

Compare every request against the approved BRS to determine in-scope, out-of-scope, or partial - in seconds, not 20-30 minutes.

AI Scope Analysis

AI provides guidance. Final scope decisions are made by admins.

Verdict

High confidence (87%)

Likely Out of Scope

Source

Based on approved BRS v1.0

Reasoning

The approved BRS (Section 3.2) specifies a fixed design system with predefined color schemes. Dark mode implementation would require redesigning the entire UI component library and was not included in the original scope definition.

BRS References (3)

similar past requests (1)

AI Ticket Extraction

Paste your demo notes or transcript, and AI will extract tickets for you

Client

TechCorp Inc.

Project

Mobile App v2.0

Demo Notes / Call Transcript

Paste your demo notes, call transcript, or meeting notes here. AI will automatically extract:

• Client name and project

• Individual ticket items

• Ticket types and priorities

• Context for each request

Paste your demo notes, call transcript, or meeting notes here. AI will automatically extract:

• Client name and project

• Individual ticket items

• Ticket types and priorities

• Context for each request

Extract Tickets with AI

Cancel

Connect with Google Drive

You can also paste links to Google Docs or Drive files. AI will access and extract tickets from the documents.

Context extraction, automatically

AI pulls missing details from vague client requests, surfaces related past tickets, and drafts follow-up questions, reducing back-and-forth before dev review.

BRS References

Section 4.2

– Settings Screen Specifications

Section 2.1

– Core UI Component Library

Section 5.4

– User Preferences Storage

Evidence-backed reasoning

Every scope verdict is paired with exact BRS references and past decisions, making classifications explainable, not subjective.

Sarah Mitchell

Fast

CR: High

Pushback: Low

Approval Rate: 78%

Human-led, AI-assisted

AI supports decisions with summaries, confidence signals, and context - final calls remain with admins and devs.

Configuration in context

Scope logic, pricing, and approvals live in contextual drawers -keeping configuration close to the decision without cluttering the flow.

For non-technical users, the primary canvas stays focused on the change lifecycle (submission → review → approval → delivery), while complexity surfaces only when needed.

Navigation through progressive disclosure

Change requests involve layered information details, scope context, approvals, pricing, and history - but exposing everything at once creates cognitive overload.

The interface uses progressive disclosure to keep primary decisions front and center, while secondary context (BRS references, AI analysis, past approvals) surfaces only when relevant. This allows non-technical users to stay oriented and confident, even as the system manages significant underlying complexity.

Faster onboarding

Standardized change workflows reduced onboarding friction and accelerated time to value.

This reduced go-live friction and helped teams demonstrate value earlier in the engagement.

AI-assisted client sentiment analysis

AI highlights early sentiment and risk signals in client communication, helping teams respond proactively and reduce conflict.

AI surfaces early signals of confusion, frustration, or urgency in client messages - allowing teams to adjust responses before tension escalates.

Previously, business teams spent close to two weeks configuring workflows, slowed by manual scope checks and repeated clarification. AI-assisted scope analysis now resolves most scoping questions upfront, reducing setup time to under four days and accelerating sales cycles.