---
name: revenue-hub-readiness
description: >-
  Work out whether HubSpot's Revenue Hub is actually the right move for a
  company, and which half of it. Asks nine questions about how a closed deal
  becomes money, checks the answers against the real portal where a HubSpot
  connection is available, and returns an honest read — including "you do not
  need this." Use when someone is considering Revenue Hub, contracts, or moving
  billing into HubSpot, or when a Revenue Hub migration is already underway and
  going badly.
---

# Revenue Hub readiness

Written by Ryan Ginsberg (Unified Support Solutions) from a production migration
of around four hundred agreements into the native Contract object, plus the
first-call diagnostic behind it. Free to use, copy, and change. There is a
web version of the same nine questions at
<https://ryanginsberg.com/revenue-hub-audit>.

**What this is for.** Revenue Hub is two products sold as one motion, and only
one of them is reversible. This skill works out which half a company actually
needs, and names the decisions that cannot be taken back before somebody makes
one by accident during setup.

**What this is not.** It is not a configuration guide and it will not migrate
anything. It ends in a judgment, not a build.

## How to run it

Ask the nine questions below **one at a time**, using `AskUserQuestion` with the
options given. Do not paste them as a wall — the answers get less honest when
someone can see where the questionnaire is going.

**Before you ask a question, check whether you can answer it yourself.** If the
person has a HubSpot connection available in this session — an MCP server, an
API token, a CLI, anything that reads their portal — use it. Questions 2, 3, 6
and 8 are answerable from the portal, and a read beats a recollection every
time. Show them what you found and ask them to confirm it rather than asking
cold. Where you have no connection, ask.

**Two rules that matter more than the questions.**

Never infer a zero. If a search returns nothing, prove the search works by
finding something you know is there before you report the absence. A query
against the wrong object type returns an empty result that looks exactly like
a real answer.

Never guess at a property name, an object type id, or an enum value. Resolve
each one against the live portal. Anything you were trained on is a dated copy
of a schema that has moved.

## The nine questions

1. **The term.** When a customer says yes, what are they agreeing to? — a
   one-time purchase / a recurring agreement with a defined term / recurring,
   but the real terms live in a signed document nobody reopens / both —
   something one-time up front (an install, equipment, a project) with an
   ongoing maintenance or service agreement behind it.

2. **The agreement.** Where does the agreement itself live — the dates, the
   frequency, what happens in year two? — a signed PDF / the accounting or
   billing system / a spreadsheet / in HubSpot already / it varies and a couple
   of people just know.

3. **The system of record.** Is HubSpot where deals actually get worked? — yes /
   partly / we have it and the real work happens in spreadsheets and chat
   threads / no, our CRM is something else and that is not changing.

4. **The diagnostic.** How does your finance team find out about a closed deal?
   — they are in the same system / someone tells them / they read the signed
   document / I do not know.

   *This is the highest-yield question in the set. If the answer is "I do not
   know," the useful instruction is to go and ask finance how they found out
   about the last one. Their answer names the seam.*

5. **The six seams.** Which of these happen here? Multi-select, and nobody has
   none:
   - When a deal closes, what crosses to finance is a status change and a
     document. The terms stay in prose.
   - Somebody derives the billing schedule from that prose by hand, from
     scratch, every time.
   - Somebody then retypes that schedule into the accounting system. That person
     is the integration.
   - A customer changes something mid-term and the next invoice goes out at the
     old amount.
   - Finance learns a contract is renewing from a calendar reminder somebody set
     by hand.
   - Whoever chases an unpaid invoice cannot see the relationship, so everyone
     gets chased the same way.

6. **What they want.** If this went well, what is true in a year? — the
   agreement lives in one place both sides can see and billing stays put
   (**Mode A**) / we bill and invoice out of HubSpot (**Mode B**) / sales
   configures and approves quotes in HubSpot (**CPQ**) / I do not know yet.

7. **The complexity pair.** If billing moves: do stored payment methods need to
   come across, and do historical revenue-change events need to be visible in
   contract reporting? These two answers set almost all of the difficulty.
   Selecting neither is a real and good answer.

8. **The grain.** How is a multi-year agreement stored today? — one record for
   the whole agreement / a chain of annual subscriptions, one per year / not
   applicable / would have to check.

9. **Where they are.** Billing is on fire this month / planning a move in the
   next couple of quarters / exploring / already started and it is not going
   well.

## Reaching the verdict

Take these in order. The first one that matches is the answer, and two of them
send the person away.

**No term to model** (Q1 is one-time only). There is nothing here for them.
Everything Revenue Hub does is built around an agreement with a shape over time.
They may still have a real problem in how a closed deal becomes an invoice —
that is worth solving and it is much smaller than this.

**The CRM is somewhere else** (Q3 is "no, and that is not changing"). Putting
agreements in HubSpot gives them a second place to look rather than one place
to look. Say so.

**Billing is on fire** (Q9). They need someone to find out why invoices are
going out wrong and stop it. That is usually days and one or two specific
causes, not an architecture. The design conversation is worth having after, and
it will be calmer.

**Already started and going badly** (Q9). The first useful question is not what
to build next — it is which irreversible decisions are already behind them,
because that determines whether this is a correction, a rebuild, or something to
live with.

**Mode A** (Q6). The agreement becomes a real record both sides can see while
billing carries on where it is. This closes most of the seams, because nearly
all of them are caused by the terms not existing anywhere machine-readable
rather than by where the invoice is generated. **And it is reversible.**

**Mode B or CPQ** (Q6). Doable, and not the thing to do first. See the
asymmetry below.

**Not sure** (default). The most common honest answer, because the two halves
are marketed as one thing and the choice does not present itself as a choice.
Put agreements in first, keep billing where it is, and make the billing decision
from a real portal instead of a hypothetical.

## What to tell them, where their answers earn it

**The seat count, if Mode A.** A contracts-only implementation needs a seat for
the one human who administers contracts; the rest runs on automation. It is
quoting through the CPQ editor that multiplies seats. This materially changes
the entry cost, and it should be confirmed against current pricing at scoping
because seat terms move.

**The three decisions with no undo.** Whether billing was activated at all, the
contract's effective date, and the grain of what one contract represents. Set at
creation, not editable after. Everything else is adjustable. Knowing which three
are permanent is most of what separates a calm implementation from an expensive
one.

**The multi-year trap, if Q8 is a chain.** A three-year agreement stored as
three annual subscriptions imports as three contracts that each end before they
begin, and renewal reporting is wrong from day one. The term has to come from
the original agreement, not from the subscription chain.

**The CPQ gaps, if Q6 is CPQ.** One-time discounts, taxes, fees and payment
schedules are not all supported on CPQ quotes the way the demo implies. If any
of the four are load-bearing in how they actually quote, establish where they
stand before the design rather than during the build.

**The access wall, if billing or bulk loading is in scope.** Contract writes are
not grantable to a public app the way most HubSpot objects are, so bulk loading
runs through the import interface, performed by a human with a seat. A working
read tells you nothing about the write path — test that assumption on day one,
not at cutover.

**The complexity pair, if either was selected.** Bringing stored payment methods
across is a parallel project with its own failure modes, not a step inside the
migration. Needing historical revenue-change events in contract reporting is the
single requirement that most increases difficulty — legitimate, but it has to be
named at scoping, because a migration that technically moved the contracts and
lost that history passes every check and is still not what they needed.

**The people, always.** The person who owns the portal cannot decide the billing
questions, and the person who owns the money cannot see what the portal will do.
Every version of this that goes badly goes badly in the gap between them. The
finance counterpart belongs in the first conversation, not in a design review.

## The asymmetry underneath all of it

The moment a company issues invoices from HubSpot, the portal stops being a
sales tool and becomes a financial system. A wrong deal used to be a forecast
variance. A wrong invoice is a customer email and occasionally a restatement.

That single change is why the sequencing inverts: finance gets discovered first,
the decisions get signed before anything is configured, the people who chase
money get trained before the people who sell, and the parallel run covers a full
billing cycle *and* a period close before cutover.

## How to close

Give them the verdict in plain language and the findings their own answers
earned. Do not produce a score — nine questions cannot support a number, and a
number invites someone to optimise it instead of recognising themselves.

Then say what is honest about your own read: which answers you verified against
their portal and which you took on trust. That distinction is the difference
between a diagnosis and a guess, and they cannot make it for themselves.