Two businesses came to us this year with the same complaint in different words. One designs and installs equipment on customer sites. The other runs several product lines through design, quote, install and aftercare, and takes on larger commercial projects alongside its smaller jobs. Both already had HubSpot. Both were losing time, and some money, in the stretch between a signed quote and a closed job.
From the inside, neither problem looked like a margin problem. It looked like admin: the same details typed twice, a job that moved forward before the survey paperwork was in, a quote follow-up nobody owned. Across a year of installs, that admin is margin. The quote was priced on the assumption that the job would run the way the estimator pictured it, and every hour of re-keying, chasing and rework comes out of that number.
These are the five places we found it going, and what we changed.
At the first business, customers, leads, jobs and support tickets weren't clearly separate records. Staff entered the same details more than once, job names and quote values were typed by hand, and customer details didn't reliably carry from sales into delivery. The install team would open a job and go looking for the site details or the equipment spec in someone's quote.
We rebuilt it around one rule: the contact is the customer, and everything else hangs off it. A sales record is created automatically when a contact is created, so nobody sets one up by hand. When the sale is approved, a job is created from it and the fields the install team needs copy across: site and property details, the specification and equipment quoted, any third-party funding details, quote value and quote number.
That structure pays twice. When the same customer comes back for an add-on, an upgrade or a second site, the new sale sits against the existing contact with its history. It doesn't start a fresh record that nobody connects to the first.
A job that reaches installation without a finished survey or an approved design costs a return visit. Both businesses had pipelines where a record could move to the next stage whether or not the work behind it was done.
For the first business we mapped delivery into stages: application, survey, design, compliance sign-offs, stock, scheduling, installation, completion paperwork, final payment and closeout. Each stage has required fields, and a job can't move on until the information for the current stage is in. We also fixed the order, so sign-offs follow design approval and completion paperwork follows the physical install, which is how the work actually happens on site.
The second business got the same treatment in its own vocabulary. There are design approval checkboxes per product line, a named design engineer on each record, and mandatory fields before a deal can progress. Record layouts show only the sections that apply to that pipeline, so a job on one product line doesn't carry a page of fields from another that nobody fills in.
The second business's process relied on people remembering. Tasks were created by hand, follow-ups lived in inboxes, and there was no rule for what should happen when a quote had sat untouched for a week.
We built workflows that create a task when a deal reaches a stage, assign it to the deal owner or the design engineer, wait an agreed period, check whether the deal has moved, and escalate if it hasn't. Closed-won deals create their related records automatically and get an incremental job number. Postcodes arriving through an external form now land in the postcode field and show on the contact card, where the field team looks for them.
They also ran several lead pipelines, one per product, which made a basic question hard to answer: where do enquiries drop out? We recommended one pipeline with lead type and segment held as fields, so time in stage and drop-off can be reported across every product line on the same basis.
This is the leak that turns straight into cash. On most install work, part of the money arrives after the job is done: the final payment, a retention, a third-party claim, or a sign-off the invoice depends on. At the first business, those steps had no clear owner. A finished job could sit waiting for a form, and the money sat with it.
Completion paperwork, final payment and closeout are now stages with owners and required fields, and the office team has its own saved view of jobs awaiting paperwork or payment. Sales see active quotes, the install team see jobs by stage, and management see incomplete jobs and outstanding requirements. Each is one screen, not a search through the full pipeline.
Whatever the gate is called in your business, the pattern holds. The last of the money waits on paperwork, and the paperwork is the part nobody owns.
The first business needed more than a personal meeting calendar. It needed one view of surveys, each trade's dates on site, confirmed and provisional installs, and which crew was on which job. A single job often carries two or three of those dates.
We reviewed HubSpot's calendar, table and Gantt-style views and an Outlook connection. The standard calendar view didn't show several install dates on one job the way an operations team needs.
Scheduling is also where the CRM usually meets another system. The second business runs separate field-service and finance software. We mapped what needs to move between them before recommending a native integration, a third-party connector or a small custom build. For most engineering and production businesses, that is the ERP to CRM question in a different form.
Neither project started in the software. Both started with how the business actually runs a job, in the team's own words. At the first business, the pipelines and tickets were renamed to match what the team already calls them. That sounds cosmetic, but it is the difference between a system people use and one they work around.
Both teams were trained to change things themselves: clone a workflow, add a field, build a segment, test an automation before it goes live. A CRM that needs a consultant for every new stage falls behind the business within a year.
What none of this fixes is a team that doesn't update the job when the work happens. Required fields make skipping a step harder. They don't make it impossible, and they don't replace a manager who opens the incomplete-jobs view every Monday.