I've spent the last few years building a CRM from the ground up, and one thing that surprised me is how many platforms are really just collections of unrelated modules glued together. What initially started as a CRM essentially became a business operating system.

You'll have customers in one place, scheduling somewhere else, dispatch living in its own world, invoicing in another system, marketing bolted on later, and payroll handled by something completely different. It works...until you start trying to make those pieces communicate with each other.

I eventually stopped thinking about building "features" and started thinking about building a business domain.

A customer shouldn't exist five different times across five different modules. There should be one customer entity. A work order shouldn't be copied into dispatch, invoicing, reporting, and marketing. It should be the same object moving through different stages of the business.

Once I started designing it that way, a lot of things became simpler.

A lead comes in---they become a customer.

A customer schedules a job.

Dispatch assigns the technician.

The technician updates the work order from the field.

Completing the work automatically updates reporting, revenue, payroll, customer history, and marketing because every module is referencing the same business object instead of trying to synchronize duplicate records.

The same philosophy applied to employees.

Most CRMs treat everyone like they're just another user account.

That never made much sense to me.

A road technician has a completely different workflow than a dispatcher. A dispatcher doesn't need the same interface as accounting. Sales shouldn't have payroll permissions.

Instead of one generic user model, I built role-specific workflows backed by RBAC so permissions are enforced on the server, not just hidden in the UI. Technicians authenticate differently than office employees because they're solving different problems.

One thing I learned pretty quickly is that architecture decisions matter a lot more than feature count.

Adding another button is easy.

Designing a data model that can support years of new features without becoming a maintenance nightmare is the hard part.

I'd rather spend an extra week redesigning a database relationship than spend the next three years working around a bad decision. 💯

Hello all, currently our team is using jobber and hubspot. For clarity we are a window and kitchen installer/distributor. We use jobber for creating quotes, schedules, jobs, and we get all our financial data through there. We just starting using hubspot as a way to track customer communication because there were gaps from our sales team that needed to be tracked.

The main issue i'm already seeing is multiple entries of clients and redundancy. Currently when customer information comes in we create the client in jobber, create the client as a company in hubspot (even if they are a homeowner) and then create the client again with the same information as a contact and associate it to the company.

Somewhere in this process we create a quote in jobber for the customer and also create a deal in hubspot so we can associate communication through the deal. This is where the issue lies is doing everything twice, I am trying to solve for this problem. Currently it doesn't seem possible to quote through hubspot at least now cost wise, i've been looking into jobbers client communication side of things and can't seem to find if its good or not.

There are also redundancies when it comes to writing out orders and invoicing but that is for another time.

This is a weekly post for you to let out about something which happened this week for you in CRM that mattered: features, client requests that were either great or awful this week, and just generally chat CRM / CRM consulting chatter.

No self promo, just a place to share tales from the front-line of CRM!