Skip to content
Index
CLIENT-ADJACENT WORKFLOW DESIGN · CONCEPTUAL PROTOTYPE

Contract Change Management Prototype

Before any production build, one question was worth answering: could a facilities/services contract-change process move from ad hoc email, spreadsheets, and document approvals into a governed, Smartsheet-first workflow? This anonymized initial-review package (diagnostic, requirements matrix, and conceptual prototype) was built to test exactly that.

Role
Discovery lead, workflow architect, prototype builder
Stage
Initial proposal
Context
Anonymized enterprise commercial real estate (CRE) / facilities
Metrics
Requirements traced · 31 · Validation gates · 16 · Prototype screens · 12
Stack
Next.js / TypeScript / Tailwind CSS / shadcn/ui / Vercel preview / Smartsheet-first architecture / Power Automate path / finance-system handoff planning
01

The Operational Problem

For a facilities/services leader managing site-specific contract scope changes, requests today typically move through emails, spreadsheets, change forms, and signature routing. That works at low volume, but repeated scope changes multiply inconsistent intake, weak margin visibility, approval ambiguity, and missing audit history. The prototype reframes the work around a single Contract Change Request object that can support site, region, finance, legal/commercial, and client approval paths.

02

System Design

Smartsheet-first workflow architecture with a standardized change-request object, contract/site master model, approval matrix, document/signature status path, finance-system handoff fields, and dashboard-ready rollups. The clickable Next.js prototype visualizes the workflow, while the Phase 0 statement of work (SOW) keeps production build, API work, active system integrations, and e-signature integration out of scope until the tenant and process gates are validated.

  • Single structured Contract Change Request (CCR) object capturing identity, scope, operational impact, financial impact (proposed price + modeled margin), approval/signature path, and finance handoff/history.
  • Approval matrix with threshold bands, triggers, delegation, and escalation rules (validation-dependent placeholders to be confirmed in Phase 0).
  • Status tracking for documents and e-signature path (signing itself remains on the existing manual path outside any prototype).
  • Finance-system handoff readiness checks with field-level exceptions and package export surface (readiness states illustrative only).
  • Portfolio and regional rollups, status views, service-line exposure, recurring vs. one-time impact, all with explicit "modeled / illustrative" markers.
03

Discovery Method

Mapped the client brief into a requirements-traceability matrix: 21 confirmed requirements, 8 inferred requirements, and 2 meeting-promoted requirements, each tied to a Phase 0 deliverable, Phase 1 solution element, dependency, alternate-platform path, and decision owner. The core correction was product judgment, not UI polish: the attached AI design had no explicit proposed-price input, which would break margin and routing for several change types.

  • 31 total requirements traced with clear Phase 0 validation targets.
  • 8 decision forks defined across intake, routing, approval, and handoff.
  • 8 Phase 0 deliverables scoped (tenant, access, workflow, pricing, documents, handoff, etc.).
  • 16 validation gates surfaced (0 validated in the prototype, all marked for Phase 0 confirmation).
04

Prototype Walkthrough

Selected views from the 12-screen conceptual Next.js prototype. Every screen carries persistent banners and inline markers: "Conceptual mockup only: no real client data, no production Smartsheet build, no live integrations." All figures, counts, prices, and states are illustrative and marked as such in the UI. Actions (submit, approve, export) are visual only. No records are created and no integrations execute. Click any frame to enlarge.

Command center / landing. Illustrative portfolio metrics, action inbox, regional snapshot, and activity. Persistent conceptual disclaimer visible.
Portfolio dashboard. Regional rollups, status distribution, service-line exposure, and request summary table. "Illustrative shape only, not measured client performance."
New Change Request intake. Structured capture of scope, price, cost, risk, and approval context in one controlled request object. All pricing/margin values illustrative.
Approvals view. Lane-filtered queue with threshold context and visual action buttons only. No routing or notifications occur.
Change Request Detail. One connected record per change, intake through handoff. Progress tracker and signature path show status only.
Scope change log. Master list with filters and saved views. Links open the connected detail record.
Phase 0 Validation gates. 16 total gates (prototype surface shows 13 representative), zero completed. Explicitly framed as the next validation step, not yet executed.
Captured walkthrough · 22sReal screen capture
Screen capture of the conceptual prototype: the control-hub dashboard with its connected change-request detail panel, the change-request log, and the lane-filtered approval queue. Client identity is anonymized, all data is synthetic, and every action is visual only. No records are created and no integrations execute.
05

Constraints & Audit Discipline

This is a conceptual prototype and diagnostic package, not a production Smartsheet build. No real client data is used in the public portfolio sample. Client identity is anonymized. The work avoids claims of completed finance-system integration, e-signature integration, legal-compliance coverage, or AI workflow automation. Phase 0 is framed as the next validation step that closes tenant, routing, document, and integration gates before Phase 1 is priced.

  • Phase 0 not started:All gates shown as open / "to validate in Phase 0." Thresholds, rate cards, burden models, and access rules are placeholders.
  • No production claims: No live Smartsheet instance, no API integrations executed, no e-signature automation, no real approvals or notifications.
  • Illustrative only: Every price, margin delta, count, and status in the prototype carries explicit markers. Submitting, approving, or exporting performs no backend action.
06

Outcome Evidence

  • 12-screen clickable Next.js prototype (hash-routed, shared mock data source for internal consistency across all views).
  • Requirements-traceability matrix: 31 total (21 confirmed + 8 inferred + 2 meeting-promoted), mapped to 8 Phase 0 deliverables and 8 decision forks.
  • 16 validation gates defined (Platform & Tenant, Access & Sharing, Workflow & Approvals, Finance & Pricing, Documents & Handoff), zero validated in prototype.
  • 6 core CCR sections modeled: identity/scope, operational impact, financial impact, approval/signature, finance handoff/history, risk/dependencies.
  • Approval matrix, threshold triggers, delegation/escalation, document version history, and handoff readiness surfaces demonstrated visually.
Scope Boundaries
  • Conceptual prototype and diagnostic package, not a production Smartsheet build or implementation.
  • Phase 0 validation gates have not been executed.
  • No real client data used in public portfolio sample. Client identity is anonymized.
  • No claims of completed finance-system integration, e-signature integration, legal-compliance coverage, or AI workflow automation.
  • Public materials use generic language only: 'finance-system handoff planning' and 'e-signature path/status'.
  • All figures, pricing, counts, and states are illustrative/modeled and marked as such in the UI.
  • Sanitized screenshots and traceability artifacts available on request.