HubSpot Implementation Specification

Implementation Summary

This document specifies a complete HubSpot build for Vigoo App: an independent commercial pipeline that converts a structured cold-email-and-WhatsApp outbound motion into qualified, attended demos, with the founders owning the close. It is a build specification, not a strategy overview. Every recommendation below is tagged to a subscription tier and validated against current HubSpot documentation. Where a capability needs a tier Vigoo App does not hold, it moves to the Upgrade Opportunities appendix and does not appear in the primary plan.

The account is greenfield. There was no CRM at intake, so there is no migration: the implementation team builds the portal clean, registered in Vigoo App's name from day one, with Epirco holding operational control through the engagement and full handover at completion. The build serves one commercial job above all others: produce a qualified, attended appointment, because that is the event the engagement is measured and paid on.

What this build includes, and what it deliberately leaves out

Timeline and team

The portal can be stood up in roughly three working weeks: week one for objects, properties, and the two pipelines; week two for forms, the WhatsApp channel, sequences, and integrations; week three for dashboards, the qualification gate, and end-to-end testing against a sample lead. The build is owned by Epirco's CRM specialist, with the dedicated part-time SDR as the primary day-to-day operator and Vigoo App's founders as the demo and close owners. A HubSpot administrator on Vigoo App's side holds the super-admin seat for handover.

2.3 Lifecycle stage mapping

The operator journey maps to HubSpot's standard lifecycle stages. The transition that matters commercially is Lead to Marketing Qualified Lead, which is gated by the lead-qualification standards, and SQL to Opportunity, which is the booked-and-attended demo. The engagement is paid on the attended demo, so the lifecycle is instrumented to make that event unambiguous.

Journey stage to HubSpot lifecycle

Forms and Capture

One form matters: the pre-qualification form that gates a demo. It lives on the custom-built vigooapp.com, not on HubSpot CMS, so it is a custom form that posts to the HubSpot Forms API. The fields map one-to-one to the qualification properties, so a submission can be evaluated by WF-2 the moment it lands. The field set is exactly the engagement's required pre-qualification data.

Form: Operator Pre-Qualification CRM

Fields and property mapping

Capture contract · custom form → HubSpot Forms API v3

# The custom vigooapp.com form POSTs server-side to the HubSpot Forms API.
# Endpoint (portalId + formGuid provided by the HubSpot admin at build):
POST https://api.hsforms.com/submissions/v3/integration/submit/{portalId}/{formGuid}

# Payload (field names use HubSpot internal property names):
{
  "fields": [
    { "name": "email",                  "value": "<email>" },
    { "name": "firstname",              "value": "<first>" },
    { "name": "ep_whatsapp_phone",      "value": "<phone>" },
    { "name": "ep_business_type",       "value": "crossfit_box" },
    { "name": "ep_active_members",      "value": "120" },
    { "name": "ep_monthly_revenue_cop", "value": "18000000" },
    { "name": "ep_role_authority",      "value": "owner" },
    { "name": "ep_city",                "value": "Bogota" },
    { "name": "ep_country",             "value": "colombia" },
    { "name": "ep_consent_habeas_data", "value": "true" },
    { "name": "ep_whatsapp_optin",      "value": "true" }
  ],
  "legalConsentOptions": {
    "consent": {
      "consentToProcess": true,
      "text": "Autorizo el tratamiento de mis datos (Ley 1581 de 2012)."
    }
  }
}
# Auth: private app token, stored server-side only. Never expose the token in client JS.

Why the Forms API and not an embedded HubSpot form: the site is a custom build, and a server-side POST keeps the private-app token off the client, lets the site own its own markup and Spanish UX, and still creates native Contact and Company records that WF-2 can evaluate. Progressive profiling and smart fields are Marketing Hub features and are not used here; if the site later wants them, see the Upgrade appendix.

Reporting and Dashboards

Four dashboards make the commercial engine legible, and they are ordered by the engagement's own priority: the first commercial KPIs the company has ever tracked are pipeline conversion and speed-to-lead, then source-level CAC, then activation. Custom report building is included at Professional, so these go beyond the default reports.

Dashboard 1: Commercial Pipeline

Audience: founders + account lead. Refresh: daily.

Dashboard 2: Speed-to-Lead & SLA

Audience: SDR + account lead. Refresh: real-time / daily.

Dashboard 3: Source & CAC

Audience: account lead + founders. Refresh: weekly.

Dashboard 4: Activation (rails-gated)

Audience: founders. Refresh: daily. Proxy-Aha reports run today; true-Aha reports populate when the rails ship.

Reporting cadence: Dashboard 2 is reviewed daily by the SDR; Dashboards 1 and 3 anchor the weekly summary; all four anchor the monthly strategic review with the account lead. Churn is instrumented from month one as the engagement's most dangerous assumption, manually at first, then from the product feed once available.

Upgrade Opportunities

Features that would benefit Vigoo App but require a tier above the current stack. None appear in the primary plan. They are ranked by the value they would deliver first, so the upgrade conversation is sequenced, not all-or-nothing.

Prioritized: #1 and #2 (Marketing Hub Professional) deliver the most value first, because they convert the manual nurture and content motion into automation as volume grows. Everything else waits on a specific scaling trigger.