CS DISPATCH — Product Design Specification
Author: Campana & Schott Consultant Date: April 9, 2026 Status: Ready for Build Day Build Day: April 17, 2026 — Miami Build Day Team: TBD (1 Builder + 4 non-builder roles)
ONE-SENTENCE PITCH CS Dispatch turns a week of fragmented project inputs — emails, transcripts, decks, and Slack threads — into a polished, conflict-resolved stakeholder update in under 10 minutes, with the Engagement Manager always in control before it sends.
1. Problem Statement
Pain Point 1 — The Friday Compilation Tax
Engagement Managers at Campana & Schott spend 1–2 hours every Friday afternoon manually compiling status updates from scattered sources: email threads, meeting transcripts, PowerPoint decks, and Slack threads. At a blended billing rate of $250/hour, this represents $500–$1,000 of billable capacity per engagement per week consumed by internal administration. Across 50 active C&S engagements, that is $25,000–$50,000 in weekly margin erosion — invisible, recurring, and entirely preventable.
Pain Point 2 — Contradictory Inputs, Invisible Risks
On any active engagement, the same fact — a go-live date, a resource commitment, a resolved blocker — may appear differently across sources. The Tuesday steering committee transcript might reference April 30. The Friday deck might say May 15. Without deliberate reconciliation, the status update that reaches the client sponsor reflects whichever source the EM happened to read last. This is not a failure of effort; it is a structural failure of tooling. One missed contradiction in a stakeholder email can materially damage client trust and, in regulated industries, create audit liability.
Pain Point 3 — Stale Context Recycled as Fresh Signal
EMs under time pressure frequently carry forward language from the prior week's update without checking whether the situation has changed. A risk flagged three weeks ago and since resolved continues to appear as active. A milestone described as "on track" in week 4 remains on track in week 7 despite slippage visible in the transcript. Without a system that tracks what was said when and surfaces changes, every update is only as good as the EM's memory — which is a fragile dependency in a high-workload consulting environment.
Pain Point 4 — Inconsistent Quality Degrades Client Relationships
The quality of client-facing communications is directly correlated with the seniority and availability of the EM that week. When an EM is traveling, in back-to-back workshops, or managing a delivery crisis, the status update either does not go out or goes out late, thin, and unreviewed. Client sponsors — typically C-suite executives with limited bandwidth — calibrate trust on consistency and clarity of communication. A missed or poorly structured update is a relationship event, not just an operational lapse.
Beneath these four symptoms is a single structural problem: consulting firms are built on the judgment of senior practitioners, but the administrative scaffolding around that judgment — synthesis, reconciliation, communication — is still entirely manual. The labor-arbitrage model tolerates this because junior hours are cheap. In an asset-creation model, where margin is the product, this tolerance becomes a liability. CS Dispatch addresses the gap at its root: replacing the manual synthesis process with an AI-native workflow purpose-built for consulting delivery.
2. Product Concept
One-Sentence Pitch
CS Dispatch turns a week of fragmented project inputs — emails, transcripts, decks, and Slack threads — into a polished, conflict-resolved stakeholder update in under 10 minutes, with the Engagement Manager always in control before it sends.
How It Works
The user experience is designed around a single weekly ritual — the Friday wrap — and has three clear stages.
Step 1: Upload & Ingest
The EM opens CS Dispatch in their browser and creates or opens the current week for their engagement. They upload or paste raw inputs into a simple intake interface: copy-pasted email threads, an uploaded meeting transcript (.txt or .docx), an uploaded status deck (.pptx or .pdf), and any Slack summaries they choose to include. No OAuth integrations, no live connections to corporate systems — the EM controls exactly what enters the system. Each input is tagged with its source type and date.
Step 2: AI Synthesis & Conflict Detection
CS Dispatch processes the inputs through its Transform Layer. It extracts structured signals across four categories: accomplishments from the past week, planned work for the coming week, identified risks or blockers, and timeline references. It then runs a conflict detection pass: any fact that appears differently across two or more sources — a date, a status, a responsible party, a resolved item — is flagged explicitly with the conflicting versions and their sources cited. The EM is presented with a Conflict Resolution panel before the draft is generated, and must make a call on each flagged item. This is the Human-in-the-Loop step: the AI cannot proceed to draft without EM input on unresolved contradictions.
Step 3: Draft Review & Send
CS Dispatch generates a structured draft update in C&S house style, organized into: Status Summary (RAG rating with justification), Accomplishments This Week (by workstream), Focus for Next Week, Risks & Mitigations (with age and trend), and Timeline Snapshot. The draft renders in a clean editor. The EM reviews, edits any section inline, and approves. On approval, the update is either copied for sending via the EM's own email client, or — in a future integration — sent directly. A read-only record of every sent update is stored per engagement for audit and continuity.
What the Client Sees
The client executive sponsor receives a consistently formatted, professionally written weekly update that arrives on time, reflects the full picture of the week's activity, and surfaces risks with clarity. They have no visibility into CS Dispatch itself — the product is invisible to them. What they experience is that C&S communications are unusually reliable, thorough, and clear.
The Strategic Play
CS Dispatch is built first as an internal C&S tool — deployed across engagements, bundled into engagement pricing, and used to recover 1–2 hours of EM time per week per project. This Stage 1 generates ROI data: time saved, quality consistency, client satisfaction correlation. Within 12 months, that data supports a Stage 2 pivot: CS Dispatch becomes a licensed SaaS product sold to other consulting firms, PMOs, and in-house transformation teams who face the same Friday problem. At $500–$800 per engagement per month, with a library of engagement templates, house-style configurations, and accumulated conflict-resolution logic, CS Dispatch becomes an asset with an 8–10x revenue multiple — exactly the transformation C&S is pursuing.
3. Target Buyer
Primary Buyer
The primary buyer is the C&S Engagement Manager (EM) — the senior consultant responsible for day-to-day delivery, client relationship management, and stakeholder communication on an active engagement. They are typically a Manager or Senior Manager, billing at $200–$300/hour, running 1–2 engagements simultaneously. Their pain is direct: Friday status updates are a recurring, time-consuming obligation that competes with billable delivery work. They are the ones who feel the 1–2 hour compilation tax most acutely, and they are the ones whose professional reputation is on the line when a status update misses a risk or contradicts something said in a steering committee.
What They Do Today
Today, the EM manually reviews their email inbox, re-reads meeting notes or transcripts from the week, scans the latest version of the status deck, checks in with workstream leads, and synthesizes all of this into a narrative email or deck. This process is entirely undifferentiated — it produces the same output regardless of whether the EM spends 30 minutes or 2 hours. Many EMs rely on a junior analyst or project coordinator to produce a first draft, which then requires significant editing. At $150–$200/hour for analyst time, even this "low-cost" approach consumes $300–$600 per week per engagement.
Why They Would Pay
The EM would pay — or advocate for C&S to pay — because CS Dispatch returns 1–2 hours of high-value time per week, replaces a cognitively draining task with a 10-minute review, reduces the professional risk of sending a contradictory or incomplete update, and produces a consistently higher-quality output than the manual process. Critically, it does not replace the EM's judgment — it amplifies it. The EM still decides what the status says. CS Dispatch simply ensures they are deciding with full information.
Secondary Beneficiary
The secondary beneficiary is the client executive sponsor — typically a VP, Director, or C-suite leader at the client organization. They do not buy CS Dispatch and have no visibility into it. What they experience is a C&S engagement that communicates with unusual consistency, clarity, and reliability. They receive updates that arrive on time, surface risks proactively, and never contradict themselves across weeks. This is a material differentiator in renewal and expansion conversations: clients remember how a consulting firm made them feel, and CS Dispatch makes them feel like they are always informed.
4. Architecture
Input Layer
CS Dispatch accepts four input types, all delivered via deliberate user action (no passive data collection):
- Email threads — pasted as plain text into a designated input field, tagged with sender and approximate date
- Meeting transcripts — uploaded as .txt or .docx files, auto-parsed for speaker turns and key statements
- Status decks — uploaded as .pptx or .pdf, text extracted from slides and tagged by slide title
- Slack/Teams summaries — pasted as plain text, no direct API connection required
The intake UI is a simple, tabbed web interface: one tab per input type, with a date field and optional source label. The EM can add multiple inputs per type (e.g., two transcripts from different meetings). Each input is stored client-side or in an encrypted, tenant-isolated database — never commingled with other engagements or transmitted to public AI endpoints without explicit routing through C&S's private model infrastructure.
Transform Layer (Core IP)
This is the defensible heart of CS Dispatch. The Transform Layer operates in three sequential passes:
Pass 1: Structured Extraction
Each input is processed through a Claude API call with a tightly scoped system prompt (a "Gem" or Skill) that instructs the model to extract only four signal types: (1) completed work items with workstream attribution, (2) planned work items for the coming period, (3) risk or blocker statements with owner and severity, and (4) timeline references with associated dates and milestones. Temperature is set to 0.1 for maximum consistency and reproducibility. Output is structured JSON, not prose, to enable programmatic comparison.
Pass 2: Conflict Detection
Extracted signals are compared across all inputs using a second Claude API call with a conflict-detection prompt. The model is instructed to identify cases where the same entity (date, milestone, status, person) appears with different values across sources, and to output a structured list of conflicts with source citations. Critically, the model is also instructed to flag items that appear in an older source but are absent from a newer one — the "stale signal" detection that catches risks marked resolved but never explicitly confirmed. The EM sees this as a Conflict Resolution panel with side-by-side source comparisons and a required resolution input before draft generation proceeds.
Pass 3: Draft Generation
With conflicts resolved, a third Claude API call generates the full stakeholder update using C&S's house template. The system prompt includes the resolved signal set, the template structure, tone guidelines (executive-appropriate, action-oriented, never passive voice on risks), and a RAG status rubric (Green/Amber/Red definitions tied to specific risk thresholds). Temperature is set to 0.3 to allow natural language variation while preserving structural consistency. The output is formatted Markdown, rendered as a clean editable document in the UI.
Project memory is maintained via a lightweight engagement log: each week's resolved signals are stored and made available as context in subsequent weeks. This allows the model to detect recurrence (a risk flagged in week 3 that reappears in week 7) and trend (a milestone that was on track in week 4 but slipping by week 6). This accumulated context is the primary switching cost and competitive moat.
Display Layer
The EM-facing UI has three main views:
- Intake View — tabbed input interface for uploading and pasting weekly materials
- Conflict Resolution View — flagged contradictions displayed side-by-side with source labels, EM selects the authoritative version or writes a synthesized resolution
- Draft Review View — editable rendered update in C&S template format, section-by-section with inline editing, approve and copy/send controls
A fourth Engagement History view shows the archive of prior weekly updates for reference and audit. All views are designed for desktop browser use; mobile is not a priority for the hackathon build.
Tech Stack (Hackathon)
| Layer | Technology |
|---|---|
| Frontend | React (Vite) — single-page app, deployed via Vercel or localhost |
| AI / LLM | Claude API (claude-sonnet-4) — three chained API calls per run |
| Backend | Node.js / Express — lightweight API layer, routes Claude calls |
| Storage | In-memory or localStorage for hackathon; SQLite for persistence |
| File Parsing | pdf-parse (PDF), mammoth.js (DOCX), custom text parser |
| Styling | Tailwind CSS — rapid professional UI |
| Deployment | Vercel (frontend) + Railway or Render (backend) — demo-ready URL |
5. Hackathon Execution Plan
Timeline Table
| Time | Phase | What Gets Built |
|---|---|---|
| 0:00–0:30 | Setup & Scaffold | React app scaffolded, Claude API connected, file upload UI skeleton, environment variables set |
| 0:30–1:15 | Extraction Engine | Pass 1 prompt engineered and tested — structured JSON output from pasted email and transcript inputs |
| 1:15–2:00 | Conflict Detection | Pass 2 prompt built — conflict panel UI rendered with side-by-side source comparison and EM resolution input |
| 2:00–2:45 | Draft Generation | Pass 3 prompt with C&S template — rendered draft output in editable UI, RAG status indicator |
| 2:45–3:15 | Polish & Demo Prep | Pre-loaded demo scenario with realistic consulting data, UI cleanup, rehearse the narrative flow |
| 3:15–3:45 | Buffer / Hardening | Fix any broken flows, add engagement history view if time allows, prepare pitch slide |
| 3:45–4:00 | Pitch Rehearsal | Full run-through of demo with team, time the narrative, confirm all judges' questions are anticipated |
Critical Risk and Fallback
The biggest risk is prompt engineering taking longer than expected — specifically, getting Pass 2 (conflict detection) to produce reliably structured, actionable output within the time constraint. Conflict detection requires nuanced model behavior and careful prompt iteration.
Fallback (if conflict detection is not demo-ready by the 2:00 mark): Collapse Passes 1, 2, and 3 into a single Claude API call that accepts all inputs and generates a draft with flagged uncertainties inline (e.g., "[NOTE: Two sources disagree on go-live date — EM to confirm]"). This is a credible, demoable product. The conflict resolution panel becomes a roadmap item. The pitch narrative shifts from "here's what it does now" to "here's the core workflow with conflict surfacing coming in v1.1." Judges will accept this if the demo still runs end-to-end.
Role Allocation Table
| Role | Specific Responsibilities on Build Day |
|---|---|
| Product Owner | Owns the build backlog and prioritization decisions. Runs the 30-minute check-ins. Makes the call on fallback at the 2:00 mark. Writes the one-slide pitch deck during the polish phase. |
| Client Advocate | Plays the EM persona throughout. Tests every UI interaction from the user's perspective. Provides feedback on draft output quality — "would I actually send this?" Owns the demo scenario: writes the realistic fake project data (emails, transcript, deck content) used in the live pitch. |
| Narrator | Owns the pitch delivery. Drafts the verbal narrative during the build phase so it is ready before polish. Ensures the demo tells a story (problem → pain → solution → proof) not just a feature walkthrough. Practices the pitch twice before judging. |
| Market Analyst | Researches and prepares the competitive landscape during the build phase. Owns Section 6 of the spec (defensibility and competitive moat). Prepares the "why not just use ChatGPT" answer. Quantifies the ROI math the Narrator uses in the pitch. |
| Pricing Strategist | Finalizes and pressure-tests the pricing model. Builds the two-stage monetization narrative (internal margin recovery → SaaS licensing). Prepares the "what would you charge us?" answer for judges. Owns the revenue multiple framing that ties back to C&S's strategic transformation. |
6. Defensibility & Competitive Moat
Why a Client Would Pay — and Keep Paying
1. Accumulated Project Memory Creates Switching Costs
Every week CS Dispatch is used on an engagement, it builds a richer signal history: what was flagged, what was resolved, what trended over time. By week 6 of an engagement, the system can tell the EM that a specific risk has been amber for three consecutive weeks without a mitigation update — a pattern no human manually tracking status would reliably catch. This history is non-transferable. If the EM switches to a generic tool mid-engagement, they lose the accumulated context entirely. The longer the engagement, the higher the switching cost.
2. Consulting-Native Structure Is Not Replicable by Generic Tools
CS Dispatch is not a general-purpose summarizer. It understands RAG status, workstream accountability, milestone cadences, and the specific professional register of executive-facing consulting communication. These are not prompt tricks — they are embedded in the template library, the extraction schema, the conflict detection logic, and the tone guidelines. A client trying to replicate this with ChatGPT would need to reverse-engineer months of prompt engineering, template design, and QA iteration. The system prompt is the IP; it is not visible to users.
3. Governance as a Feature, Not a Constraint
CS Dispatch is built on the principle that client data never touches a public model. In regulated industries — financial services, healthcare, government — this is not a preference; it is a procurement requirement. By building the governance model into the product architecture from day one (private API routing, tenant isolation, audit logs), CS Dispatch can go where generic AI tools cannot. This opens client segments that are systematically excluded from the competitive set.
Pricing Model
Stage 1 (Internal, Year 1): CS Dispatch is bundled into C&S engagement fees at no additional client-facing cost. The value is captured as margin improvement: $500–$1,000/week/engagement in recovered EM capacity, at 50 active engagements = $1.25M–$2.5M in annual margin recovery. This is the ROI case for internal adoption.
Stage 2 (External SaaS, Year 2+): CS Dispatch is sold as a standalone product at $600/engagement/month. Pricing is anchored to value displaced: $2,000–$4,000/month in EM and analyst time saved, making the $600 price point a 5–6x ROI proposition. At 100 paying engagements, ARR = $720K. At 500 engagements (a realistic mid-market consulting PMO customer base), ARR = $3.6M. At a SaaS multiple of 8–10x, this represents $28M–$36M in asset value — from a product built in an afternoon.
Competitive Positioning
| CS Dispatch is NOT… | Why not | What it is instead |
|---|---|---|
| A project management tool | Does not track tasks, assign owners, or manage dependencies. No Gantt charts. | A communication synthesis tool — it reads PM tool outputs, not replaces the tool. |
| A generic AI writing assistant | ChatGPT and Copilot have no project memory, no consulting structure, no conflict detection. | A purpose-built consulting communication engine with accumulated project context. |
| A meeting transcription service | Otter.ai and Fireflies transcribe; they do not synthesize, reconcile, or produce stakeholder deliverables. | A downstream synthesis layer that consumes transcripts as one of several inputs. |
| A CRM or client portal | Salesforce, HubSpot — relationship tracking, not project communication synthesis. | A delivery tool, not a relationship management tool. |
The closest analogue is Notion AI applied to project notes — but without the conflict detection, the consulting-native template structure, the multi-source reconciliation, or the governance wrapper.
7. Success Criteria
Hackathon Demo (April 17) — Checklist
The following must be true for the demo to be credible to judges:
- EM can upload or paste at least two different input types (e.g., transcript + email thread) into the intake UI
- System successfully extracts structured signals (accomplishments, risks, timeline refs) from both inputs
- At least one genuine conflict is detected and surfaced in the Conflict Resolution panel with source citations
- EM can select the authoritative version of the conflicting fact and proceed
- A complete, formatted draft update is generated in C&S template structure with RAG status
- The draft is editable inline before approval
- The full workflow runs end-to-end in under 10 minutes in the demo
- The demo uses realistic consulting scenario data — not Lorem Ipsum or obviously fake content
- The product runs on a live URL accessible to judges on their own devices
"Would a Client Pay for This?" Test
The pitch must satisfy all five of the following criteria to pass the judging standard:
- The ROI math is explicit and credible — judges can follow the calculation from time saved to margin recovered to dollar value without being asked to trust an assertion.
- The Human-in-the-Loop step is visible in the demo — judges must see that the EM reviews and approves before anything goes to the client. No demo should show an update being auto-sent.
- The "why not ChatGPT" question is answered before it is asked — the narrative proactively addresses generic AI alternatives and explains the moat.
- The data governance model is stated clearly — judges from regulated industries will ask. The answer must be crisp: client data is routed through C&S's private API infrastructure and never sent to a public model endpoint.
- The two-stage monetization story is told — judges evaluating the 8–10x multiple thesis need to see the path from internal tool to licensable SaaS asset, with a credible ARR number attached.
8. Open Questions
The following are genuine unresolved design decisions that the team must work through on Build Day:
1. What is the right granularity for conflict detection?
Conflicts can be detected at the fact level (specific dates, names, statuses) or at the narrative level (the general picture of a workstream differs across sources). Fact-level detection is more precise but may miss important narrative contradictions. Narrative-level detection is richer but harder to surface as a clean, actionable UI element. The team must decide during prompt engineering which approach is realistic to demo in 4 hours — and which produces output an EM would actually trust.
2. How do we handle incomplete or low-quality inputs?
Not every week will have a clean transcript or a structured email thread. Some inputs may be bullet-point notes, forwarded chains with quoted text, or informal Slack dumps. The system needs a graceful degradation strategy: what does CS Dispatch do when the input is too sparse to extract meaningful signals? Does it prompt the EM to provide more, generate a low-confidence draft with explicit caveats, or refuse to proceed? This edge case will definitely appear in a live demo if not anticipated.
3. What is the right balance between template rigidity and EM customization?
The C&S house template is a core part of the value proposition, but different engagements have different communication norms — some clients want a three-line summary, others want a detailed workstream breakdown. If the template is too rigid, EMs will edit it heavily and the time savings erode. If it is too flexible, the product loses its consulting-native identity. The team should define at least two template modes (executive summary vs. detailed breakdown) for the hackathon and test which judges find more compelling.
4. How do we demonstrate engagement memory in a one-afternoon build?
Project memory is the primary switching cost and competitive moat — but it requires multiple weeks of real engagement data to demonstrate convincingly. In a hackathon context, this has to be simulated: pre-loaded prior week data that the system references when generating the current week's draft. The team must decide how much of the demo to spend on this feature versus the core extract-conflict-draft workflow, and whether a simulated memory demonstration is credible enough to carry the moat argument with judges.