Map Custom Fields for Tracking Agency Service Lines

You are a RevOps architect who specializes in multi-service-line agencies and knows how to model bundled deals without making the CRM unusable.
Agency: [AGENCY_NAME] | CRM: [CRM_TOOL] | Service lines: [SERVICE_LINES] | Bundle frequency: [BUNDLE_FREQUENCY] | Reporting need: [REPORTING_NEED] | Delivery model: [DELIVERY_MODEL]
Design a custom field structure that captures, for every deal, which service lines are included, the MRR/one-time fee per line, and the delivery owner per line. The structure must support reporting on service mix, per-line revenue, and AM capacity.

- Choose between line items, custom objects, or per-service-line custom field groups based on what [CRM_TOOL] actually supports — call out the tradeoff
- Each service line must have: revenue type (MRR/one-time), amount, start date, end date (or null), delivery owner, status
- Solution must roll up to a deal-level total without manual math
- Avoid creating 40 custom fields — be surgical

Section 1: recommended architecture (line items vs custom object vs field groups) with reasoning. Section 2: field-by-field spec table. Section 3: 3 example deals (single-service, bundle, expansion) showing how data lives in the system.

• [AGENCY_NAME] — Your agency's name
• [CRM_TOOL] — HubSpot, Pipedrive, Salesforce, etc.
• [SERVICE_LINES] — Comma-separated list of services you offer
• [BUNDLE_FREQUENCY] — What % of deals include 2+ services
• [REPORTING_NEED] — What you need to report on (margin per service, AM load, etc.)
• [DELIVERY_MODEL] — Pod-based, service-line teams, individual AMs, etc.}

Agency: Rally Growth | CRM: HubSpot Pro | Service lines: SEO, Paid Search, Paid Social, Email/Lifecycle, Creative Production | Bundles: 65% of deals are 2+ services | Reporting: per-service MRR, AM capacity, expansion attribution | Delivery: service-line pods

**Architecture:** Use HubSpot line items (native object) instead of custom fields. Pros: rolls to deal amount automatically, supports per-line owner, plays nicely with quotes. Con: line item reporting is weaker than deal reporting — pair with a custom Service Line Snapshot object for monthly per-line MRR tracking.

**Line Item Fields**
| Field | Type | Required | Notes |
|---|---|---|---|
| Product (service line) | Lookup | Y | Library: SEO Retainer, Paid Search, Paid Social, Email, Creative Sprint |
| Revenue Type | Picklist | Y | MRR, One-Time |
| Monthly Amount | Currency | Y if MRR | — |
| Start Date | Date | Y | — |
| End Date | Date | N | Null = ongoing |
| Service Owner | User | Y | Pod lead |
| Status | Picklist | Y | Active/Paused/Churned |

**Examples:** (1) SEO-only deal = 1 line item. (2) SEO+Paid+Creative bundle = 3 line items, 3 owners, rolls to $11k MRR. (3) Expansion = new line item added to existing deal, original lines untouched.

• Use line items, not multi-select fields, when bundles are common — multi-select can't hold revenue per line.
• Build the Service Line Snapshot object so you can answer 'what was paid social MRR in March 2025' without time-travel headaches.
• Standardize the Product library upfront. Reps will create 'SEO,' 'SEO Retainer,' and 'SEO ' (with a trailing space) if you let them type.