HubSpot that does what your business believes it does.
My deepest platform experience is in HubSpot and the systems connected to it. I take responsibility for defined HubSpot work: how it is structured, how records and stages are set, the automation and connections around it, and, where it fits, its own AI. Each change is examined before it is made, tested against what depends on it, and handed over so your team can run it.
HubSpotOne shared record of every company, contact and deal, and one set of automation acting on it.
How I workNot a fourth area of expertise: the platform where much of the work in all three is done, and where a change made for one can quietly reach the others.
How I work
What I can take responsibility for
Situations, not packages.
These are the situations people usually bring. Each is scoped to your account: what you want to hand over, what has to be known first, and where the work stops.
Mark the situations that draw on
Eight situations. Most draw on more than one area.
01Setting HubSpot up, or restructuring one that grew without a planDraws on: Revenue systems, Demand & ABM
You can hand over
A HubSpot organised around how you sell and market: objects, pipelines, lifecycle, ownership, permissions and naming, set up or reorganised in a planned order.
What it involves
Working out what exists and who relies on it, what to keep and what to retire, and the order of changes that keeps everything in use working.
What I check first
Your subscriptions, who holds admin rights, what is connected, and which teams and reports depend on what is there now.
Where it stops
A restructure within HubSpot. Migrating another CRM into HubSpot is not something I take on; moving from another marketing platform is scoped first, as part of a wider change.
02Records that describe your business the way it actually worksDraws on: Revenue systems
You can hand over
Objects, properties and associations for your companies, contacts, deals and whatever is particular to your business, with definitions people can find.
What it involves
Deciding where a standard object fits, where a property or an association label is enough, and where a custom object is justified.
What I check first
Your edition (some objects and features depend on the subscription), and which forms, workflows, reports and integrations already rely on the properties you have.
Where it stops
The data model inside HubSpot and its documented definitions. Cleaning a large historical dataset is scoped separately, if at all.
03Leads that reach the right person, at the right stageDraws on: Revenue systems, Demand & ABM
You can hand over
Lifecycle stages and lead status with agreed definitions, and the scoring, routing and automation that apply them.
What it involves
Agreeing what each stage means and who may set it, then building the rules, and testing them with real cases, including the awkward ones: existing customers, missing countries, duplicates.
What I check first
What sets each stage today, whether records will ever need to move backwards, and how owners and teams are assigned.
Where it stops
The definitions are yours to agree; I make them precise, build them and show where they break. Sales forecasting stays with your sales leadership.
04Data moving reliably between HubSpot and the tools around itDraws on: Revenue systems, AI workflows
You can hand over
Native integrations and HubSpot’s data sync configured, with field mappings designed and what happens on failure written down; light connections through HubSpot’s API where the scope is small, testable and recoverable.
What it involves
Which system owns each field, what happens on conflict and on failure, and how anyone would know that something stopped.
What I check first
Who owns the system at the other end, the access each side allows, and what already writes to the same fields.
Where it stops
Bounded connections with a named owner on each side. Enterprise middleware, large custom integration engineering and deep Salesforce work need a specialist in that system.
05Finding out why a workflow, record or report cannot be trustedDraws on: Revenue systems, Demand & ABM, AI workflows
You can hand over
A read-only investigation that ends in findings you can check, each saying how it is known, and the options for fixing them.
What it involves
Property history, workflow settings and enrolment, what writes each field and in what order, and how the report is defined.
What I check first
Read access. HubSpot keeps a limited number of past values for each property, and some settings may not be readable through its API, so they are checked in HubSpot itself.
Where it stops
Findings and options. Nothing is changed during an investigation.
06HubSpot’s own AI, used where it has been checkedDraws on: AI workflows
You can hand over
A bounded use of AI inside HubSpot workflows for one defined job, tested on your cases before you rely on it, with a person or a rule where the outcome matters.
What it involves
Choosing between HubSpot’s AI actions and a model you connect, writing the instruction, deciding what the AI may change, and testing it, including with deliberately misleading input.
What I check first
Which AI features your subscription includes, whether they use HubSpot credits, who may change AI settings, and whether a plain rule would do the job.
Where it stops
One defined job at a time, inside your HubSpot. No custom models, and nothing that acts without a person or a rule where it matters.
07A change made, proven and handed overDraws on: Revenue systems, Demand & ABM, AI workflows
You can hand over
One configuration change made under a written plan: the before-state captured, the change made in stages, what depends on it tested, and a record your team can run from.
What it involves
A change record, stop rules, an independent re-read, and an honest account of anything the change cannot undo.
What I check first
What depends on the thing being changed, and what HubSpot can and cannot restore if it goes wrong.
Where it stops
The agreed change and its handover. Anything found along the way is reported, not quietly fixed.
08Defined specialist time, or steady improvementDraws on: Revenue systems, Demand & ABM, AI workflows
You can hand over
Delegated responsibility for a defined part of your HubSpot, for a set term and capacity; or support and improvement with explicit coverage and an end date.
What it involves
Working to your priorities inside an agreed boundary, with every change recorded the same way.
What I check first
Which part of the system is in scope, who decides priorities, and who holds admin rights.
Where it stops
A defined part of your system over an agreed term: not open-ended administration, an undefined operations remit or full-time availability.
Not what I take on
Where the work needs a specialist in another system, or cannot be tested and recovered responsibly, I say so at the start, and say what kind of specialist it needs.
Deep Salesforce administration or architecture
Enterprise middleware or large custom integration engineering
CRM-to-CRM migration programmes
Any integration or migration whose risk, testing or recovery cannot be properly controlled
Responsibility for your sales forecast
Open-ended administration, or an undefined operations remit
How I approach the work
Why a small HubSpot change needs a systems view
Imagine a form that marks every enquiry as sales-qualified. Changing one setting may seem straightforward, but the consequences depend on your definitions, automation, ownership and reporting. This walkthrough shows how I would investigate the requirement, work through the options and check the effect of a change.
A CRM field can look correct after a change while its history and reporting values have changed. That is why meaningful verification goes beyond checking a single setting.
What should “sales-qualified” mean, and who decides?
The approach Start from the business rule, not the setting. Until it is agreed and owned, there is nothing to engineer.
Inspecting the flow shows that a “Contact sales” form makes every person who submits it sales-qualified at once, and that nobody has defined what sales-qualified means. The fix is not a setting. It starts with a definition that sales and marketing both accept.
A business-rule ambiguity rather than a configuration defect: the form sets the lifecycle stage to sales-qualified lead on submission, and the property history shows the form as the source. Without an agreed definition of a sales-qualified lead, there is nothing to test a change against.
What the inspection showsA business-rule ambiguity
The “Contact sales” form makes every submitter sales-qualified immediately, and sales-qualified has no agreed definition.
The property history shows the form setting the stage at the moment of submission.
To agree with you before anything changes
Sales-qualified means
the evidence sales accepts
Who may set it
a person in sales, or a rule both teams accept
A form submission may
raise the stage to an agreed point, and no further
Owner of the definition
named
Step 2 of 6Examine the platform
What sets the stage, and what depends on it?
The approach Map what writes the field and what reads it before touching anything, and say which parts could not be seen.
Three things write to these contacts: the form, an import and a routing automation. What reads the stage matters as much: views, automation, reports, and HubSpot’s own dates recording when each contact entered and left each stage. Some settings can only be confirmed by looking in HubSpot itself.
Writers, from property history: the form (the stage), an import that updates contacts matched on email, and the routing workflow (owner and lead status). Whether lifecycle stages sync between contacts and companies is a setting to check in HubSpot. API permissions determine what an integration can read, so a workflow’s settings may have to be inferred from history and confirmed in the interface. Pipeline rules, reports and segments that read the stage are checked too.
What wrote to these contacts
The “Contact sales” formForm submission · history source: formSet the stage on submission
An importImport · updates contacts matched on emailCreated and updated contacts
The routing automationWorkflow · history source: automationSet owner and lead status, not the stage
Lifecycle stageLifecycle stage property
What reads it, and what to check
HubSpot’s stage dates and durationsCalculated date entered, date exited and time-in-stage valuesRecalculated whenever the stage changes
Contact-to-company stage syncLifecycle settings · sync lifecycle stagesA setting to check in the HubSpot interface
The routing automation’s settingsWorkflow settings, through the APIDepending on API permissions, confirmed from history and in HubSpot itself
Pipeline rules, reports and segmentsPipeline rules · reports · segmentsChecked before any change, not assumed
Step 3 of 6Decide the approach
Fix the source, then decide what to do about the records.
The approach Lay out the real options and what each one costs, including what cannot be undone, then decide with the people who own the outcome.
Changing the form stops new wrong labels. The contacts already labelled are the harder question: moving them back makes the label right, but rewrites their stage dates, which reports may rely on. Leaving them and recording the correction elsewhere keeps the dates, but every report then has to use the new field.
Options: (a) change the form only, so it stops setting sales-qualified on submission; (b) change the form, then move the affected contacts back, which needs the stage cleared and then set for each record and rewrites HubSpot’s calculated stage dates and time-in-stage values; (c) change the form, then mark the affected contacts on a separate property and leave the lifecycle stage alone. The choice depends on which reports, lists and workflows read the stage and its dates, so that is checked first.
The options for correcting the form and the affected contacts
Option
What it fixes
What it costs
Can it be undone?
Change the form only
New submissions
Contacts already labelled stay wrong
Yes: the form setting can be changed back
Change the form, then move the affected contacts backTried in a controlled test
The labels
Their stage dates are rewritten; reports that use them shiftThe stage cleared, then set, for each record; calculated stage dates rewritten; history keeps both moves
Not fully: see step 5
Change the form, then mark the affected contacts separately
The labels, without rewriting dates
Every report has to use the new field
Yes
Decided with the people who own the definition and the reports that read the stage. Their answer, not the tool, picks the option.
Step 4 of 6Engineer the change
Try the change on two records first, under a written change record.
The approach Write down what will change, how it would be reversed and when to stop, then make the change in stages.
To learn what the second option costs, the change was tried in a controlled test before any wider correction. A written record set out the two contacts, the values to watch, how the change would be reversed and three reasons to stop. The first contact was changed and checked before the second was touched. HubSpot’s forms, imports, workflows and API only move a stage forwards, so going back took two steps for each contact: clear the stage, then set it.
Change record: two contacts; watched: lifecycle stage, lead status, owner, country, email and HubSpot’s calculated lifecycle dates and durations. Reversal: a compensating write setting the stage back, stated in advance as not necessarily restoring the calculated values. Stop if any write errors (for example, a pipeline rule blocking the move), if the first record does not read back as Lead with everything else unchanged, or if any automation writes to owner, lead status or stage afterwards. Writes: clear the lifecycle stage, then set it to Lead.
Change
Move two contacts from sales-qualified back to Lead, then restore them.
Watched
Stage, lead status, owner, country, email, and the stage dates and durationsLifecycle stage, lead status, owner, country, email; calculated lifecycle dates and durations
Before-state
Read fresh and saved before the first write
How it would be reversed
A write setting the stage back. Stated in advance: this may not restore the calculated dates.
Released in stages
Contact 1, check, then contact 2
Stop if
Any write fails, for example a pipeline rule blocking the move
Contact 1 does not read back as Lead with everything else unchanged
Any automation writes to owner, lead status or stage afterwards
Cannot be undone
The history entries for the change and the restore remain
Going back takes two writes per contact
1Clear the stageSet the lifecycle stage to empty
2Set it to LeadSet the lifecycle stage to Lead
HubSpot’s forms, imports, workflows and API only move a stage forwards. To go back, it has to be cleared first.
Step 5 of 6Test what depends on it
The stage came back. Its dates did not.
The approach Check the change, then everything that depends on it, after the platform has settled; report what did not come back.
No automation reacted to the change, and a separate read-only check agreed. Then the stage was set back. The stage itself came back, but most of the dates and durations HubSpot keeps for each stage did not: the record now shows a period as a Lead it never really had. HubSpot recalculates those values in the background, so a check made too soon can miss differences; checks need to wait until repeated readings agree.
No automation wrote to the watched values after the change, and an independent read agreed. Restoring the stage succeeded, but the calculated entered, exited and time-in-stage values for Lead and sales-qualified lead did not return to their earlier values, and the stage history keeps both moves. Because recalculation is asynchronous, reconciliation reads repeatedly until consecutive readings agree.
Set back to sales-qualified. The stage is right again; most of its dates and durations are not.
How the values moved for one of the two contacts in the test
Value
Before
Moved back
Restored
Lifecycle stageLifecycle stage
Sales-qualified lead
Lead
Sales-qualified leadBack
Date entered sales-qualifiedDate entered, sales-qualified lead (calculated)
Original date
Original date
Reset to the restoreDiffers
Date exited sales-qualifiedDate exited, sales-qualified lead (calculated)
empty
Set
Still setDiffers
Latest time in sales-qualifiedLatest time in sales-qualified lead (calculated)
empty
Recorded
Still recordedDiffers
Total time in sales-qualifiedCumulative time in sales-qualified lead (calculated)
empty
Recorded
Still recordedDiffers
Date entered LeadDate entered, lead (calculated)
empty
Set
Still setDiffers
Date exited LeadDate exited, lead (calculated)
empty
empty
SetDiffers
Latest time in LeadLatest time in lead (calculated)
empty
empty
RecordedDiffers
Total time in LeadCumulative time in lead (calculated)
empty
empty
RecordedDiffers
One of the two contacts in the test. 8 of the values shown did not return to where they were.
Step 6 of 6Prepare for handover
A record the team can run from.
The approach Hand over what changed, why, what it cannot undo and how to run it, to a named person who did not build it.
On a real account, the handover would say what was changed and why, who owns the definition of sales-qualified, which reports were affected by the rewritten dates, how to correct the remaining contacts in batches under the same stop rules, and what to watch over the following weeks.
Handover contents: the change record and its reconciliation; the agreed definition and its owner; the form setting before and after; the list of affected contacts, from history; the dashboards and reports that read the calculated stage dates, with their expected shift; the batch procedure with stop rules; how to reverse the form change.
What changed, and why. The change record and its reconciliation.
The agreed definition of sales-qualified, and its named owner.
What did not come back. The rewritten dates, and the reports that use them.
How to finish the job: the remaining contacts in batches, under the same stop rules.
What to watch, and for how long.
How to undo the form change.
The test of a handover: someone who did not build it can run it, and knows when to stop.
How I work
Before committing to a change
What has to be known first.
A small, clear change needs little of this. A change that touches many records, other systems or something that cannot be undone needs more, and that work comes first. These are the questions behind the time it takes.
01
Permissions
Who can change what, and what access the work itself needs.
In HubSpot, for example
Some actions, such as restoring recent CRM changes, are limited to particular admin permissions.
API permissions determine what an integration can read and change; access must match the work required.
What I do
Ask for the least access the work needs, say in writing what it allows, and keep build and inspection access apart where the account allows it.
02
Editions and licences
What your subscription actually includes, before anything is designed around it.
In HubSpot, for example
Features such as custom objects and AI actions in workflows depend on the subscription, and what each tier includes changes over time.
Some AI features draw on HubSpot credits, so their running cost is part of the design.
What I do
Check the account first. If a design needs a feature you do not have, say so and offer what works without it.
03
Dependencies
What reads and writes the thing being changed.
In HubSpot, for example
One property can drive lists, workflow triggers, reports and integrations at once.
HubSpot keeps a limited history for each property, so older values may not be recoverable.
What I do
Map what writes and what reads before the change, and say what could not be seen.
04
Complexity
How many moving parts there are, and how sure anyone can be about them.
In HubSpot, for example
A workflow’s settings may not be readable through the API, so its role has to be inferred from record history and confirmed in HubSpot.
A newly created record can take a few seconds to appear in search, so a check that searches too soon can miss it.
What I do
When the cause or the reach of a change is unclear, scope it first: a bounded investigation that ends in a decision.
05
Recovery
What can be undone, how, and what cannot.
In HubSpot, for example
Merging records is hard to undo.
Moving a lifecycle stage back, then forward again, may not restore its stage dates.
HubSpot’s tool for restoring CRM changes covers a limited period and only supported kinds of change.
What I do
Write the recovery plan before the change. Where something cannot be undone, decide it explicitly and in advance.
Platform details change often, so they are checked against HubSpot’s own documentation on each account.
The work behind it
Experience and engineering in HubSpot
My HubSpot work combines CRM and marketing operations experience with practical engineering: system structure, lifecycle processes, automation, integrations and intelligent workflows. Explore a client engagement and selected technical approaches below.
Tell me what HubSpot should be doing that it is not.
A rough description is enough: the report nobody trusts, the leads that reach the wrong person, the workflow everyone is afraid to touch, or the setup you want right from the start. The first step is usually to look before anything is changed.
We use optional analytics cookies to understand how this site is used and improve the experience. You can accept or reject them at any time.Privacy Policy
Cookie & analytics settings
Choose whether this site may load analytics. Your choice is stored on this device and can be changed here whenever you like.
NecessaryAlways active
Needed to operate the website and the HubSpot contact form. No analytics or advertising cookies. This cannot be switched off.
Google Tag Manager (GTM-5X33PT7C), Google Analytics 4 (G-L5MM4C1V01), Microsoft Clarity (w3leigv39l) and the HubSpot tracking code (242075805). Used to measure and improve the site: aggregate page views, navigation paths, and anonymised interaction and session data. HubSpot also records the pages you view, may identify your organisation from your IP address, and links those visits to any enquiry you later send. Nothing loads or sends data until you allow it here.
Ask MarOps Lab
Ask about the services, the work, or whether a situation is a fit. This assistant answers from what’s published on this site; Osama replies to enquiries personally.
Try one of these
Please don’t include personal or confidential information.
