HubSpot CRM Implementation for a UK Scientific Services Organisation
An unsupported SharePoint-based CRM left sales teams with low adoption, poor data quality, and gaps in reporting and forecasting. We configured HubSpot as the target CRM. The client, a UK scientific services and research organisation, serves agri-food regulators and manufacturers. The data model was built around project and contract sales, RFPs, sample requests, and finance-system dependencies.
Executive Summary
Context
Commercial records had to support scientific testing, consultancy, research, and project work without flattening the approval and finance controls behind them. The implementation defined HubSpot companies, contacts, opportunities, products, line items, Projects, Events, and Event Attendees, then separated commercial motions into Project and Contract Sales, RFP, and Sample Requests pipelines.
When this was documented, the programme was still in UAT and migration preparation, so this Blueprint covers the architecture and build decisions rather than post-launch performance.
What We Built
HubSpot received a CRM architecture for project and contract sales, RFPs, and sample requests, supported by custom Projects, Events, and Event Attendees objects. Company and opportunity properties captured sector and service segmentation, finance identifiers, project data, governance data, and separate commercial amount fields.
The build also included permissions and team assignments, pipeline configuration, event-registration workflows, lead and enquiry routing, product-library import, UAT materials, migration planning, and an offline deal-tracking template for the gap between legacy CRM retirement and HubSpot go-live.
Tech Stack
- HubSpot
- NetSuite
- SharePoint
- Node.js
This implementation is not evidence of completed adoption, reporting, forecasting, data quality, or revenue improvement. It also does not document a finished two-way NetSuite integration: when this was written, the Phase 1 customer sync was still in progress, and the broader bidirectional design sat outside that executed Phase 1 scope.
The Challenge
Sales teams could not rely on the legacy SharePoint-based CRM for consistent reporting or forecasting, and the existing HubSpot estate had collected legacy workflows and forms over several years. The replacement had to support project-based commercial work, a public-science approval model, and customer identities governed by NetSuite.
NetSuite created a second constraint: once a Project is created against a customer, changing that customer means reversing every transaction on the Project. A Closed Won deal therefore could not create a finance project from incomplete or wrongly matched customer data.
Our Approach
HubSpot stage requirements were built to turn commercial readiness into record-level data rather than relying on policy alone. Each pipeline stage specified its own required fields, and Closed Won was treated as a documented contract state with confirmed value, defined deliverables, start and end dates, and required fields completed.
A custom Proposal object in NetSuite sits between HubSpot Closed Won and NetSuite Project creation. Commercial data enters the Proposal first, finance validates the customer, contract value, and dates, and a Project is created only after those checks. The design returns the Project ID to HubSpot and creates a mirrored HubSpot Project record.
Customer matching was handled before project creation through NetSuite Company ID enrichment, a unique identifier for future imports and external-ID use, and a notification path for quoted opportunities that have no ID yet. Original Estimated Amount and Actual Contract Amount are kept separate when finance actuals differ from the original commercial estimate.
Impact
Closed Won was defined as a data contract
Closed Won now means a signed contract. It requires confirmed and documented value, defined deliverables, start and end dates, and completed required fields. Accountability sits with the sales representative even where project management or finance supports contracting.
Approval controls were modeled in the CRM
Committee and leadership approvals were modeled as permission-restricted properties, an approval-file requirement, and an approval-date requirement. The pipeline is designed so a deal cannot reach Quoted until the required approval information is in place.
Finance and sales values remained distinct
Original Estimated Amount and Actual Contract Amount are kept as separate values. When finance actuals diverge, the commercial estimate isn't overwritten. The record preserves the documented distinction between sales expectations and finance-confirmed contract values.
The retirement gap had a controlled bridge
An offline deal-tracking template covers the period between legacy CRM decommission and HubSpot go-live. It captures the fields a bulk upload needs at switchover. Unlicensed colleagues get a controlled route for occasional updates.
Three opportunity pipelines separate Project and Contract Sales, RFPs, and Sample Requests. Standard HubSpot objects sit alongside custom Projects, Events, and Event Attendees objects. Project delivery and event participation associate with the commercial record without forcing every motion through one pipeline.
NetSuite customers become immutable after Project creation, and the Proposal staging pattern was designed around that fact. A HubSpot Closed Won deal writes commercial data into a custom NetSuite Proposal object. Finance validates customer, value, and dates there before creating a Project.
Project creation requires a customer already present in NetSuite, so NetSuite Company ID was added to companies and opportunities. Existing companies were prepared for bulk ID enrichment. The ID became a unique identifier for future imports and external-ID needs. A notification flags quoted opportunities with no ID.
Event registration runs on Event and Event Attendee custom objects with ID-based associations. Each registration link carries the Event Attendee ID as a URL parameter. The submission then updates the existing attendee record instead of creating a duplicate. Cloned event workflows and segments, renamed and repointed for each event, form the operating model.
HubSpot contains companies, contacts, opportunities, products, line items, Projects, Events, and Event Attendees. Project and Contract Sales, RFP, and Sample Requests use separate opportunity pipelines. At Closed Won, commercial data is designed to pass from HubSpot to a custom Proposal object in NetSuite. Finance validates the customer, contract value, and dates before NetSuite creates a Project. The resulting Project ID returns to the HubSpot opportunity, where a mirrored Project record is created. NetSuite Company ID is required before the project handoff.
FAQ
The documented build centers on HubSpot as the target CRM, NetSuite as the finance system of record, and a legacy SharePoint-based CRM as the migration source. Marketing Hub was already in use. Sales Hub was in scope. Service Hub and Tickets were explicitly out of scope.
No. The programme had not gone live when this was written, and the source material contains no post-launch adoption, data quality, reporting, forecasting, revenue, or time-saving measures. The evidence covers architecture, build progress, UAT preparation, and planned migration and go-live activity.
