Chapter 2.13 Capstone Project

Why This Chapter Matters

The Part II capstone certifies that an engineer can apply the complete CRM automation architecture to a previously unseen client scenario making design decisions without per-step guidance and producing a system that would function in a real deployment. The Vantage Advisory Partners scenario introduces a financial services context with distinct compliance expectations, a different intake channel mix, and a client whose team will need to operate and maintain the system without ongoing engineering support. Applying a known architecture to an unknown domain is the professional competence this capstone assesses.

Real-World Scenario

Vantage Advisory Partners is a fee-only financial advisory firm serving high-net-worth individuals. The firm receives inquiry through a website contact form, conference introductions, and referrals from existing clients. Current intake relies on the founding partner’s personal judgment about which inquiries to pursue a process that works at ten inquiries per month but is failing at thirty. The capstone asks engineers to design and deploy the full Part II CRM intelligence platform adapted to Vantage’s client profile, compliance requirements, and operational context.

Learning Objectives

After completing this capstone, you will be able to:

  • Apply the complete Part II CRM automation architecture to a financial advisory domain, adapting all four workflows, the nine-layer model, and the governance layer to Vantage’s client profile and operational context.
  • Design and document the HubSpot property schema for the Vantage platform, specifying property ownership, field types, and the lifecycle state machine appropriate for a fee-only advisory firm.
  • Build the hybrid AI scoring layer adapted to Vantage’s investor qualification criteria, with prompt engineering, confidence band configuration, and audit trail logging appropriate for a regulated financial services context.
  • Produce a complete set of ADR-style design decisions documenting your architectural adaptations, with written rationale for each departure from the Part II reference architecture.
  • Demonstrate professional readiness for Part III by producing a platform that operates correctly at Vantage’s submission volume, handles the governance scenarios described in the brief, and can be handed off to the client’s team.

Builds On

  • Chapters 5.1 through 5.12 (complete Part II architecture)

Prepares For

  • Part III AI Systems Engineering

2.13.1 Before You Begin

This capstone simulates a full professional engagement. You are the automation engineer on a real client project. The deliverables you produce requirements document, working platform, verification report, handover package, and retrospective are the deliverables a client would receive at the close of a real engagement. Write them accordingly.

Prerequisites. Sections 5.1–5.12 complete. This capstone is the final Part II deliverable.

Partner sign-off gate. Treat the completion of Deliverable 1 as the client approval gate. In a real engagement, you would not begin HubSpot configuration until a partner had reviewed and approved your Requirements Document. In this simulation, reviewing Deliverable 1 against the self-review checklist in §2.13.4.1 before beginning Deliverable 2 enforces the same discipline. Do not begin Deliverable 2 until that review is complete.

Time. Plan for 35–55 hours.

The most commonly underestimated phases are HubSpot property configuration (creating 40+ custom properties manually takes 3–5 hours), handover document quality (each document requires a separate writing session to reach partner-readable standard), and prompt calibration iteration.

Budget a minimum of two uninterrupted sessions for configuration and at least one dedicated session per handover document.

2.13.2 The Engagement

Vantage Advisory Partners is a boutique management consulting firm with nine partners and eleven associates across two offices. The firm advises mid-market companies ($20M–$300M revenue) on operational strategy, organizational restructuring, and technology transformation. A review of the last 18 months identified 31 inquiry opportunities where follow-up activity was absent or critically delayed, representing approximately $180,000 in lost engagement revenue. The firm has retained you to design and implement a CRM intelligence platform that prevents that attrition.

Engagement types and qualifying signals.

Type Duration Fee range Primary qualifying signals
Assessment 6 weeks $45K–$85K Budget authority ≥ $50K, decision timeline ≤ 8 weeks, problem well-defined
Engagement 12 weeks $90K–$180K Budget authority ≥ $100K, timeline ≤ 12 weeks, organizational sponsor identified
Transformation Program 6 months $200K–$400K Budget authority ≥ $200K, C-suite sponsor, multi-year strategic mandate referenced

Lifecycle stages. New Inquiry → Qualified Prospect → Proposal Sent → Negotiation → Active Engagement → Completed → Closed Lost. Closed Lost is a terminal state: once a contact reaches it, no automated lifecycle transitions are possible, all follow-up automation terminates, and manual_override_active is cleared.

Operational constraints.

  • No automated outbound messages to prospects without explicit partner approval. All follow-up messages must be drafted by Workflow C and reviewed by an associate before sending.
  • Partner notifications route to #vap-partner-review (lifecycle transitions at Qualified Prospect and above), #vap-ops (operational alerts: new inquiries, touchpoints, survey completions), or #vap-alerts (escalations only).
  • All Slack notifications must be 3–5 lines and include score, lifecycle stage, and recommended next action.
  • Any score change ≥ 5 points triggers a #vap-ops notification.
  • Any inquiry from a company the firm has previously declined must be flagged for partner review regardless of advisory score.

Technical environment. HubSpot CRM (Professional tier), Typeform Business, Slack, n8n.

2.13.3 Discovery Call Record

Review the Discovery Call notes below before beginning Deliverable 1. They document Managing Partner Sarah Chen’s confirmed scope, capacity constraints, notification preferences, and conflict-of-interest protocol all of which must be reflected in your Requirements Document.

Discovery Call Notes Managing Partner Sarah Chen (55 minutes)

Participants: Lead Automation Engineer (you), Managing Partner Sarah Chen Duration: 55 minutes

Definition of a “good” inquiry. A company representative with budget authority, a defined problem that maps to one of the firm’s three engagement types, and a decision timeline within 12 weeks. Inquiries meeting all three criteria should reach a partner within 24 hours of receipt.

Associate capacity. Each of eleven associates handles a maximum of two active engagements simultaneously, for a ceiling of twenty-two concurrent active engagements. Current load is approximately fourteen.

Inquiry volume. 8–12 per week at peak (Q1, Q3). 3–5 per week off-peak (Q2, Q4). Conference season (March–April, September–October) produces surges of 15–18 per week for two to three consecutive weeks. The scoring model must hold up under surge conditions without false-positive escalations.

Partner notification preferences. #vap-partner-review only for Qualified Prospect stage transitions and above. Operational alerts to #vap-ops. Escalations to #vap-alerts. Sarah Chen’s explicit preference: “I don’t want to see a notification every time someone fills out a form. I want to know when someone is ready to talk to me.”

Conflict-of-interest protocol. Any inquiry from a company the firm has previously declined to engage must be flagged for partner review, regardless of advisory score. This flag must be stored as a HubSpot Contact property (vap_conflict_of_interest_flag) and checked in Workflow A before any scoring or routing occurs.

Follow-up philosophy. “We are a relationship firm. We would rather not follow up than follow up in a way that feels automated.” All automated follow-up messages are drafted by Workflow C and made available in HubSpot Notes for associate review. The associate approves by advancing the contact to the next lifecycle stage manually. No fully automated outbound messages to prospects.

Go-Live requirement. Partner confirmation required before Go-Live. Sarah Chen will confirm via a direct message to #vap-ops. Do not activate workflows in production before that message is received.

2.13.4 Your Deliverables

Seven deliverables constitute the completed engagement. The order below is the recommended build sequence. Do not begin Deliverable 2 until you have completed the self-review checklist in §2.13.4.1.

2.13.4.1 Deliverable 1: Discovery and Requirements Document

This document represents the scope agreement you would present to a partner for approval. Write it as a partner-readable document, not an engineering spec a non-technical partner should be able to read it and understand exactly what will be built, what will not be built, and what decisions they are approving.

Required sections: engagement summary / four-workflow architecture overview / HubSpot data model summary / governance model summary / out-of-scope items / assumptions log (minimum five entries) / risk register (minimum three risks with likelihood, impact, and mitigation approach).

Self-review checklist complete before beginning Deliverable 2:

2.13.4.2 Deliverable 2: HubSpot Data Model Specification

A complete property inventory for the Vantage CRM platform, organized into six required property groups. The internal name prefix for each group must be consistent across all properties in the group and across all n8n workflow implementations.

Required property groups.

Group Required properties (minimum)
VAP Intake Source channel, engagement type interest, stated budget range, decision timeline, conflict-of-interest flag
VAP Advisory Score Current score, previous score, score delta, score tier, scoring timestamp, score version
VAP Lifecycle Governance Current stage, previous stage, last transition date, manual_override_active, override reason, override timestamp, override partner
VAP Follow-Up Cadence TP1 sent, TP2 sent, escalation sent, last touchpoint timestamp, touchpoint count
VAP Survey One property per Typeform question (see Typeform Field Mapping below)
VAP Audit Last workflow execution timestamp, last workflow name, last score change magnitude, evaluation source

Typeform Field Mapping required sub-section.

Your data model must include a Typeform Field Mapping table for the pre-engagement questionnaire. You design the question text, field types, and HubSpot property internal names. The six question topics are fixed:

  1. Project scope description what the prospect wants to accomplish
  2. Current state description the prospect’s current situation or primary challenge
  3. Decision timeline by when the prospect needs a consulting partner engaged
  4. Key stakeholders who from the prospect’s organization would be involved
  5. Prior consulting engagements whether the prospect has worked with consultants before and with what outcomes
  6. Budget authority whether the contact has authority to approve an engagement fee without additional internal approval

Typeform Field Mapping Table Template

For each of the six questions, complete one row of the following table. This table is the contract between Workflow D and the HubSpot property schema. Inconsistency between this table and your n8n extraction paths or HubSpot property definitions will be cited in Criterion 1 and Criterion 5 evaluation.

Column What to specify
Typeform field label The question text as it appears in Typeform
Typeform field type short_text, long_text, multiple_choice, date, yes_no, or equivalent
n8n extraction path The JSON path from the Typeform webhook payload (e.g., $.body.form_response.answers[0].text)
HubSpot property internal name Must use survey_ prefix (e.g., survey_decision_timeline)
HubSpot property type single_line_text, multi_line_text, enumeration, date, boolean, or number
Rescore flag condition The condition that sets requires_rescore_review = true. Write “None” if no condition applies.

All six rows must be completed before beginning Workflow D implementation.

2.13.4.3 Deliverable 3: System Integrity Verification Report

Post-build verification of the complete four-workflow platform. This is evidence that the system works not a description of how you built it.

Required verification areas: workflow execution confirmation (at least one successful execution per workflow, with evidence), PERMITTED_TRANSITIONS testing (at least three forbidden transitions tested and rejected), governance gate verification (manual_override_active = true suppresses automated lifecycle transitions), and idempotency testing (Workflow D with a duplicate survey submission produces no new property writes and no additional rescore flag evaluation).

Scoring Calibration required sub-section.

Include a dedicated sub-section titled “Scoring Calibration” in Deliverable 3. A scoring model where any priority tier is unreachable by a real client payload fails Criterion 6 regardless of other calibration documentation.

  1. Submit a test payload designed to produce the maximum possible formula output. Record the actual score produced.
  2. Confirm the result exceeds your Hot-tier threshold. If it does not, identify the miscalibration source (formula weight, cap value, or tier boundary) and document the correction.
  3. Submit one test payload per tier and confirm all four tiers are reachable. Present results as follows:
Tier Threshold range Test payload description Score produced Tier reached
Hot
Warm
Cool
Cold
  1. State the formula’s minimum and maximum achievable scores and confirm these bounds are consistent with your tier boundary definitions.

2.13.4.4 Deliverable 4: End-to-End Scenario Trace

A documented walkthrough of one contact’s complete journey from initial inquiry through Workflow D survey completion. The contact must traverse at minimum four lifecycle stage transitions.

For each transition, document: the trigger condition, the detecting node, the PERMITTED_TRANSITIONS check outcome, the Slack notification sent (channel and content), and the HubSpot property state after the transition. Include the Typeform survey submission and confirm that Workflow D correctly writes all six survey properties and evaluates the rescore flag condition.

2.13.4.5 Deliverable 5: Workflow Export Package

Four .json workflow exports, one per workflow. Each export must be importable into a clean n8n instance without manual node reconfiguration. Use placeholder credential names, not hardcoded API keys.

2.13.4.6 Deliverable 6: Handover Package

Four documents and two Architecture Decision Records. All six components must be readable by a non-technical partner no n8n-specific terminology, no JSON syntax, no workflow node names in the four documents.

Four documents.

Document Audience Required content
Partner User Guide Non-technical partner Monitoring the system; what each Slack channel contains; what to do when #vap-partner-review receives a notification; how to set manual_override_active; escalation contacts
Technical Implementation Notes Technical successor Credential locations; webhook URLs; workflow names and trigger conditions; HubSpot property group prefixes; deployment environment
HubSpot Property Inventory Anyone Every custom property: internal name, display name, type, and the workflow that writes to it
Governance Reference Card Non-technical partner (one page) PERMITTED_TRANSITIONS matrix; conditions that set manual_override_active = true; score change notification threshold; conflict-of-interest flag behavior

Two Architecture Decision Records.

An ADR documents a consequential architectural choice so that any future engineer or partner can understand why the system is built the way it is and what would break if that choice were reversed.

ADR-A Deal Creation Lifecycle Trigger. At which lifecycle stage does n8n create a HubSpot Deal record for this contact? Your ADR must address: what a partner sees when a Deal appears in the pipeline and why premature or delayed Deal creation has operational consequences; which stage you chose as the trigger; why Qualified Prospect and Proposal Sent were or were not the right choices; and the decision’s impact on pipeline revenue reporting accuracy and partner visibility into potential revenue.

ADR-B Follow-Up Cadence Interval Design. What are your TP1, TP2, and Escalation time intervals for Vantage’s consulting consideration cycles? Your ADR must address: the typical decision timeline for a management consulting engagement at Vantage’s target client size; whether fixed-time intervals or activity-based triggers are more appropriate for a relationship-first firm; your specific interval values in business hours; and the consequences for partner relationship expectations and the governance cooldown duration.

ADR Format Template

Use the following structure for both ADR-A and ADR-B. Length: 250–400 words per ADR.

Title: A short, descriptive title for the decision

Status: Decided

Context: What situation required this decision? What constraints or trade-offs were present?

Decision: What did you choose? State it directly.

Alternatives Considered: What else was evaluated, and why was each alternative not chosen? Name the alternative and give the reason for rejection.

Consequences: What does this decision enable? What does it constrain? What would a future engineer need to know before changing it?

Review Condition: Under what changed circumstances should this decision be revisited? Name a specific trigger condition.

2.13.4.7 Deliverable 7: Engagement Retrospective

The retrospective is a professional reflection on what you built, what you would change, and what this system cannot do that a more advanced architecture could. Three components are required.

Component A Technical Retrospective.

  1. What was the most technically difficult design decision you made during this engagement, and how did you resolve it?
  2. What would you configure differently in a second engagement with a firm of this type?
  3. Where is the system most likely to fail in a production environment, and what monitoring would detect the failure earliest?
  4. Which of your ADR decisions (ADR-A or ADR-B) do you expect to be revised first, and under what condition?

Component B Part III Bridge.

Answer the following with specific architectural reasoning. General statements about “better AI” or “more powerful models” do not satisfy these questions name the specific limitation and the specific architectural change that would resolve it.

  1. The current system’s AI advisory calls are synchronous, single-model, and single-context: one inquiry produces one API call with no awareness of other contacts in the pipeline or of historical scoring patterns. Identify two specific scenarios where this single-call constraint produces a suboptimal outcome for Vantage that a multi-agent or multi-context AI architecture would resolve.

  2. Workflow C polls for contacts on a fixed interval. Identify one scenario where event-driven follow-up triggering reacting to a HubSpot Contact property change rather than a polling cycle would produce a materially better outcome. Describe the architectural change in Workflow C that would implement it.

  3. The governance layer uses a boolean flag (manual_override_active). Describe one specific scenario where richer governance state an override with an expiry timestamp and a reason code would prevent a real operational error that the current boolean flag cannot prevent.

Component C Portfolio Case Study.

Write a 400–600 word Problem-Solution-Outcome narrative for your professional portfolio, following the format taught in Chapter 2.12. Audience: a prospective consulting firm client reading your work samples.

Problem (100–150 words). What challenge was Vantage Advisory Partners facing? What was the operational cost? Use specific numbers from the brief.

Solution (200–250 words). What did you build? What does each of the four workflows do? What governance mechanisms are in place? Plain language no n8n or HubSpot terminology.

Outcome (100–150 words). What can Vantage now do that it could not do before? Project specific outcomes using numbers from the brief: the 31 identified missed opportunities, the $180,000 lost revenue baseline, the firm’s capacity ceiling of twenty-two active engagements. Write in operational terms, not architectural terms.

Vantage Advisory Partners is a simulation scenario designed for portfolio use. Write as if Vantage authorized you to include this engagement in your professional portfolio. If you have not yet completed Chapter 2.12, complete Component C after that section.

2.13.5 Evaluation

Your capstone is evaluated across seven criteria. The passing threshold is 78 of 100 points.

Criterion 1 Intake Processing and AI Advisory Accuracy: 18 points

Sub-criterion Points
1.1 Workflow A triggers correctly on all four intake source channels 3
1.2 Conflict-of-interest flag check occurs before advisory scoring and routes to #vap-partner-review when flagged 4
1.3 AI advisory output is extracted, parsed, and written to VAP Advisory Score property group with correct types 4
1.4 Typeform field mapping in Deliverable 2 matches the n8n extraction paths and HubSpot property internal names in Workflow D 4
1.5 evaluation_source property is correctly set to "ai" or "rule_fallback" on each execution 3

Criterion 2 Score Constraint Verification: 12 points

Sub-criterion Points
2.1 Returning contact score preservation logic is implemented: the current score is not replaced when the new score is lower 5
2.2 Score preservation is verified with a documented test: a returning contact with a declining score retains the previous higher value 4
2.3 Score delta is correctly calculated and written to the VAP Advisory Score property group 3

Criterion 3 Governance Gate Enforcement: 20 points

Sub-criterion Points
3.1 manual_override_active = true suppresses all automated lifecycle transitions for the affected contact 6
3.2 Any score change ≥ 5 points triggers a #vap-ops notification containing score, delta, and tier 5
3.3 Override activation and deactivation are logged in the VAP Lifecycle Governance property group with timestamp and partner name 5
3.4 Both ADR-A and ADR-B use the required seven-field format and address all specified questions 4

Criterion 4 State Machine Integrity: 17 points

Sub-criterion Points
4.1 PERMITTED_TRANSITIONS matrix is documented in Deliverable 1 and enforced in Workflow B 5
4.2 At least three forbidden transitions are tested in Deliverable 3 and correctly rejected by the system 5
4.3 manual_override_active = true suppresses automated transition triggers but does not prevent manual HubSpot stage updates from being logged in the VAP Lifecycle Governance property group 4
4.4 Closed Lost is treated as a terminal state: manual_override_active is cleared, follow-up cadence terminates, and no further automated lifecycle transitions are possible 3

Criterion 5 Survey Idempotency: 8 points

Sub-criterion Points
5.1 Workflow D checks whether survey properties have already been written before writing 3
5.2 Duplicate survey submission is tested in Deliverable 3: a second identical submission produces no new property writes and no additional rescore flag evaluation 3
5.3 The idempotency mechanism is documented in the Technical Implementation Notes 2

Criterion 6 Scoring Calibration: 10 points

Sub-criterion Points
6.1 Scoring Calibration sub-section is present in Deliverable 3 1
6.2 Maximum formula output is documented with a test payload and exceeds the Hot-tier threshold 4
6.3 All four score tiers are reachable by real client payloads; verified with documented test payloads per tier 4
6.4 Formula minimum and maximum achievable scores are stated and consistent with tier boundary definitions 1

Criterion 7 Documentation and Portfolio: 15 points

Sub-criterion Points
7.1 All four Handover Package documents are complete and written in non-technical language throughout 5
7.2 Engagement Retrospective Component A addresses all four technical retrospective questions with specific examples from this build 3
7.3 Engagement Retrospective Component B addresses all three Part III bridge questions with specific architectural reasoning, not general statements 4
7.4 Portfolio Case Study (Component C) follows the Problem-Solution-Outcome structure, uses client language, references specific numbers from the brief, and is within the 400–600 word limit 3
ImportantCritical Requirement

Part III Readiness Gates

To be cleared for Part III, you must meet the overall passing threshold and all three sub-thresholds below. A passing total score with any sub-threshold unmet requires remediation of the failing criterion before Part III enrollment.

Criterion Sub-threshold Why this gate exists
Criterion 1 Intake Processing ≥ 14 / 18 Workflow A is the platform’s architectural foundation; gaps here compound across the other three workflows
Criterion 3 Governance Enforcement ≥ 18 / 20 Governance is Part II’s distinguishing competency; Part III multi-agent systems require this discipline at higher architectural complexity
Criterion 7 Documentation and Portfolio ≥ 12 / 15 Part III AI systems engineering requires rigorous architectural documentation; readers who cannot produce professional-grade deliverables will face compounding difficulty at Part III’s specification requirements