Portfolio Demo · Operations Systems

Multi-Source Intake & AI Triage System

A production-style demo for mid-size operations and content teams that consolidates messy requests from multiple channels, normalizes them into a canonical system of record, enriches them with AI, and exposes role-based workflow views for triage, execution, and visibility.

View repo

What this demonstrates

System design

Multiple source adapters, a canonical schema, and explicit pipeline stages.

Data modeling

Raw source snapshots, normalized requests, triage outputs, runs, and audit events.

AI-assisted triage

Deterministic summary, routing, priority inference, and confidence-based review.

Workflow UX

Different interfaces for triage managers, contributors, and stakeholders.

Live System Snapshot

Canonical requests

Duplicates caught

Low-confidence triage

Urgent or critical

Recent canonical requests

Before-and-after normalization in context

csvMediumMarketing

DUPLICATE - Blog post: 5 Tips for Remote Team Collaboration

Raw department: Marketing

AI department: Marketing

Raw type: Blog Post

Final type: Blog Post

Submitted Feb 10, 2025 by Sarah Chen

csvMediumCustomer Success

Customer win announcement: Meridian Health

Raw department: Customer Success

AI department: Marketing

Raw type: Blog Post

Final type: Blog Post

Submitted Feb 25, 2025 by Rachel Kim

csvCriticalMarketing

Webinar invite email + registration page copy

Raw department: Marketing

AI department: Marketing

Raw type: Webinar Copy

Final type: Webinar Copy

Submitted Feb 23, 2025 by Sarah Chen

Problem

Multi-channel intake sounds flexible until no one trusts the queue.

Operations and content teams often receive work through project-management tools, spreadsheet uploads, internal forms, and Slack threads. The result is predictable: duplicate submissions, inconsistent labels, missing priorities, and no shared definition of what a request actually is. This demo treats intake quality as a product problem, not just a form problem.

Why it matters

The value is operational clarity, not an Airtable clone.

The goal is to show how intake systems should absorb messy reality: retain source context, normalize what can be normalized, surface uncertainty where needed, and give each persona a view that matches the decisions they need to make.

Architecture

A modular pipeline with explicit handoffs

Intake sources map into a shared canonical model through validation, normalization, dedupe, and AI enrichment layers. The same records then power persona-specific workflow views without source-specific branching in the UI.

Data Model

Canonical request plus supporting operational tables

requests

source_records

ingestion_runs

departments

request_types

users

triage_results

assignments

request_events

The schema keeps both the original source record and the canonical request, which is critical for debugging mapping errors, explaining overrides, and building operator trust. Prisma + SQLite keeps the demo portable, while the schema shape stays ready for Postgres later.

Ingestion Sources

Three intentionally messy entry points

Webhook simulator

Simulates third-party PM payloads with variant keys like `task_name`, `subject`, and `cardTitle` plus mixed date formats and priority casing.

CSV importer

Parses partner spreadsheet uploads, emits row-level statuses, and catches duplicates against the canonical request table.

Native form

Represents the cleanest path, while still routing through the same validation, normalization, and AI layers.

AI Triage Design

Swap-friendly service boundary, deterministic demo mode

The AI layer predicts summary, department, request type, and priority from title, description, and notes. Confidence scores drive the review queue. The current demo uses a local deterministic classifier so the artifact stays reproducible, but the code is shaped so a live provider can replace it without changing the UI contract.

Role-Based Workflows

Views optimized for decisions, not just data access

Team Lead / Triage Manager

Needs-review queue, low-confidence AI results, duplicate signals, and override controls.

Individual Contributor

Assigned work, due dates, and request context without triage noise.

Stakeholder / Requestor

Simple dashboard view of submitted requests, owners, and status progress.

Key Product Decisions

Preserve both raw payloads and normalized records so debugging never depends on guesswork.

Treat normalization and AI triage as separate layers so human operators can see which fields came from source mapping versus model inference.

Bias the lead view toward exceptions: low confidence, duplicates, warnings, and urgent deadlines.

Keep the demo deterministic with a mock AI provider abstraction so the architecture is interview-friendly and provider swap is trivial later.

Tradeoffs Considered

SQLite keeps the demo portable, but a real customer deployment would likely move the same Prisma schema to Postgres for concurrency and observability.

The AI layer is deterministic by default to keep the portfolio artifact reproducible. That reduces realism compared with a live provider, but it improves explainability in an interview.

The demo focuses on workflow depth over authentication. Personas are simulated instead of fully auth-gated to keep the project self-contained.

Slack Recommendation

What I would recommend to a real customer next

Why intake is breaking down

Slack often contains the richest context first, but formal entry happens later in fragmented tools, which creates lag, duplicate submissions, and missing detail.

Recommended future architecture

Slack message shortcut → structured modal → intake API → source record created → canonical request + triage result → channel confirmation.

Implementation phases

Start with structured modals for high-volume teams, then add thread-to-request linking, automated reminders, and channel-specific analytics.

Recommendation

This is the kind of system I would pitch as an operational foundation, not just a workflow tool.

For a real customer, I would prioritize cleaner intake contracts, a durable event history, explicit ownership rules, and a Slack-first front door. The system becomes more valuable as the team grows because it reduces queue ambiguity, accelerates triage, and preserves institutional context.