Case Study:

How Greenwich Tent Company Built a HubSpot System That Actually Runs Their Operations

Client: Greenwich Tent Company
Engagement: Ongoing. March 2025 to present
HubSpot Hubs: Marketing Hub Pro · Sales Hub Pro
How We Connected: Upwork 

 

The Situation

Greenwich Tent Company rents high-end tents and event structures across the Northeast. They do weddings, corporate events, galas, and large-scale productions — the kind of work that requires serious logistics coordination, not just a sales process.

By the time we started working together, they were generating a healthy volume of inbound inquiries. The problem wasn’t leads. The problem was what happened to them after they arrived.

Inquiries were coming in from multiple sources — their website, Cvent, The Knot, WeddingPro — each with different field names, different data structures, and no consistent path into HubSpot. Leads landed unassigned. Stages drifted. The sales team wasn’t working from a single source of truth, and the operations team had no clean system to manage what happened after a deal closed.

A growing business with real demand, running on manual workarounds and institutional memory instead of infrastructure.

That’s what we set out to fix.

What a Fractional HubSpot Admin Actually Does Here

This engagement isn’t a one-time build. It’s an ongoing working relationship — I’m embedded in their operations, attending regular team calls, responding to questions as they come up, and evolving the system as the business changes.

That’s the fractional model: you get a senior HubSpot expert working inside your org without hiring one full-time. For a company like Greenwich Tent — where the volume and complexity of work genuinely requires HubSpot expertise, but not 40 hours a week of it — it’s the right fit.

Over 12+ months, the work has covered CRM architecture, custom object implementation, workflow engineering, sales team enablement, and post-contract operations. Here’s how it came together.

Building the CRM Foundation

Four Pipelines, Not One

The first architectural decision: Greenwich Tent doesn’t have one kind of deal. They have several — different event types, different client relationships, different operational needs. Running all of it through a single default pipeline was creating reporting bleed and obscuring what was actually happening in each segment.

We built four distinct pipelines, each mapped to a specific business type. That separation means conversion data is clean, stage definitions mean what they’re supposed to mean, and the team isn’t trying to force different sales processes into the same structure.

Standardized Lead Intake Across Every Source

Every inbound channel got standardized: website forms, Cvent, The Knot, WeddingPro. Field mapping was normalized across all of them so that regardless of where an inquiry originated, it entered HubSpot with consistent structure — assigned to the right pipeline, routed to the right owner.
No more leads falling through because a field name didn’t match. No more unassigned contacts sitting in the queue.

The Three-Layer Data Model

The backbone of the CRM architecture is a three-layer model:

Contact → Deal → Custom Event Object

The Deal record is the source of truth for all event-specific data during the sales process. Contact-level fields (name, email, phone) sync read-only to associated records — clean, one-directional, no data drift.

When a deal closes, a workflow fires that copies all relevant Deal properties to the custom Event object. Sales and operations are working from the same data, in different workspaces designed for their specific roles.

The Custom Event Object: Where Operations Actually Live

This is where the build gets interesting.

Most HubSpot setups treat the Deal as the end of the road. Close the deal, mark it Won, done. For Greenwich Tent, closing a deal is when the real work begins — there’s an entire production and logistics operation that has to happen between contract and event day.
We built a custom Event object (their internal term: Project Manager object) to hold that work.

At the point of Closed Won, a workflow fires that: 

  • Creates a lean Event record (Event Name, Pipeline, Stage, Contact Phone, Primary Contact, Owner)
  • Fires a second set of Edit Record steps with a delay to populate the remaining 26+ properties from the Deal
  • Assigns PM group ownership based on branching logic (Kate + Ashley, Yasmin + Ashley, Maddie, or Ashley solo)

The PM object is then structured around operational phases:

Kickoff → Pre-Production/Compliance → Logistics & Scheduling → Production Packet → Install → Event Day → Close-Out

Each phase has its own task structure using HubSpot Projects native functionality, with phase-level dependencies. The operations team has a workspace that reflects how they actually run events — not how HubSpot thinks a generic service pipeline should work

Separating Requirement Tracking from Completion Tracking

One of the design principles I’m most deliberate about: requirement tracking and completion tracking are different questions and they live in different places.

On the Deal, conditional dropdowns capture whether a job needs specific logistics: Ferries, Overnight Accommodations, Crew Meals, an Engineer, Electrician, Plumber, Rain Plan. These questions get answered during the sales process, when the team knows what’s involved.

On the Event object, those requirements become execution tasks. Two separate concerns, no field overlap, no confusion about which record to look at for which question.

Workflow Governance: Fixing What Was There First

Before building new automation, we audited what existed. What we found was a common pattern in accounts that have grown organically: workflows built on the wrong object type, a property sync running backwards, enrollment logic that created more problems than it solved.
Specifically:

Multiple workflows were enrolled against the wrong object, which made properties unavailable and created backwards data flow
A property sync workflow was moving data Deal → Contact when it needed to go Contact → Deal
Automation had been added over time without a governing principle, so triggers conflicted and enrollment was unpredictable

We corrected all of it, then established a governance framework that’s been the standard for every workflow built since:

Enrollment object = source. Edit Record steps = target associated object.

Simple rule. Prevents a whole category of errors.

We also implemented date filters on all automation triggers — critical when deploying new workflows into a live account with historical deal records. Without those filters, every old deal can enroll in a new workflow the moment it goes live. That’s a data hygiene disaster that’s easy to prevent and easy to miss.

What the Team Said

“TJ has been a key player in helping us get the most of our HubSpot account. We needed assistance with setting up workflows, adding in automations and templates and helping with the dashboards that we use to see our company growing. She also was able to help us with lead scoring which has been incredibly helpful to assess our lead quality. She is knowledgeable, helpful, quick and efficient. At this point, she’s basically a member of our team and her hard work and dedication is greatly appreciated. Can’t recommend her enough!”

— Kacie Finch, Greenwich Tent Company ★★★★★ 5/5 | HubSpot Solutions Partner Profile | January 2026 Services: CRM Implementation, Programmable Automation, Email Marketing, Customer Marketing

What This Engagement Actually Delivered

  • Every inbound lead routes to the correct pipeline with a defined owner — the unassigned drift is gone
  • The sales team works from clean, consistent data regardless of which intake channel generated the lead
  • Post-contract operations run from a dedicated custom object — sales and PM aren’t trying to work out of the same record
  • Workflow automation handles PM assignment, property population, and stage routing — manual steps eliminated
  • The system is documented and governed, not tribal knowledge — new team members can be onboarded to it

The bigger outcome: HubSpot now reflects how Greenwich Tent actually operates, at every stage from first inquiry to event close-out.

What Made This Engagement Different

Real fractional administration — not a project handoff. Most HubSpot work gets scoped as a one-time build. This is ongoing: I’m in their system, on their calls, evolving the build as their business evolves. That continuity is what allows a system this detailed to actually get maintained.

Post-sales architecture isn’t an afterthought. Most HubSpot builds stop at Closed Won. We built forward — the custom Event object is where Greenwich Tent’s actual value delivery lives, and it required as much architectural thinking as the sales side.

Governance before features. Before adding new automation, we fixed what was broken. The workflow audit and governance framework mean everything built on top of it is stable — not a new layer of complexity on top of existing problems.

The enrollment object rule changed how they build. Establishing a clear governing principle for workflow logic — enrollment object = source, Edit Record = target — gave the operations team a framework they can use without calling me for every decision.

Technologies & HubSpot Features

HubSpot Sales Hub Pro · HubSpot Marketing Hub Pro · Custom Objects · HubSpot Projects (native) · Workflow Automation (Contact, Deal, Custom Object enrollment) · Property Sync · Pipeline Architecture · Form Strategy & Field Mapping · Deal-based Lead Routing · Lead Source Standardization · E-Signatures (in scope)

Greenwich Tent Co
N

What was built

✦ 4-pipeline CRM architecture
✦ Custom Event / Project Manager object
✦ Multi-source lead intake & routing
✦ Automated PM assignment & task structure
✦ Post-contract operations system
✦ Workflow governance framework

N

Key Skills

Fractional HubSpot Admin
Custom Object Design
CRM Architecture
Workflow Engineering
Revenue Operations
Sales Enablement

N

★★★★★ 5/5

Kacie Finch
“She’s basically a member of our team.”