Sage 100

Does anyone have experience or familiarity with Housecall Pro (HCP)?  Apparently Zapier has an integration for Sage 'Accounting' but not necessarily specifically for Sage 100, although I'm told HCP has an open API.  And it sounds like most of their customers use QuickBooks but I guess they have plenty of folks who use the Zapier integration.

from AI/copilot:
Housecall Pro is a cloud-based field service management platform designed for home service businesses such as plumbing, electrical work, HVAC, and cleaning. It offers a range of features including scheduling, invoicing, dispatching, and customer management, making it an end-to-end solution for managing business operations. Founded in 2013, Housecall Pro aims to help service professionals thrive by providing innovative tools and financial services. Trusted by over 45,000 businesses, it is recognized as a leading software solution in the home service industry. 

------------------------------
Brett Zimmerman
Net at Work
Greater Boston Area
------------------------------

I haven't heard of it.  Tell the end-user that the most important part of any "integration" is defining exactly what the integration level is and how much effort they will have to put into designing the integration themselves.

------------------------------
Wayne Schulz
wayne@s-consult.com
Schulz Consulting
(860) 516-8990
CT
------------------------------

I second Wayne's advice and expand a bit.

I used to do CRM, and integration was always a thing. ERP systems that had native integrations were always attractive, but the CRM piece was always less useful for the sales and marketing team that had to use it than other "straight" CRMs. 

Part of what seems to drive Management's drive for integration is that they think want one set of reporting, both detail and summary, for all of it. That simply never works because the details from the CRM (or service dispatch and management) simply don't match the ERP systems data architecture. They need to have a kick-ass system for capturing customer calls, needs, schedules, and deliveries which also handles the annual service plans and such. 

The only integration needed between the service and ERP systems are 

• Customer information necessary for billing, order creation, and invoicing. Details stay in service, but the info needed for AR is shared.
• Orders for service calls and service plans can go either way, but mostly from service into ERP because the people creating them are in service. 
• Product details. Look how cimcloud and other ecommerce integrations work. That model is exactly what is needed here. Basically these details are created in Sage and synched to service system, not the reverse. 
• Detailed customer service reporting is out of the service module, but company-wide data about best customers & products. 

When you break down the integration needs like this, you see that daily integration jobs are sufficient. Suddenly, this becomes a VI project at its simplest.

------------------------------
Jerry Norman
Smartbridge Partners
(512) 653-7498
------------------------------

Original Message:
Sent: 04-17-2025 11:37
From: Wayne Schulz
Subject: Housecall Pro

I haven't heard of it.  Tell the end-user that the most important part of any "integration" is defining exactly what the integration level is and how much effort they will have to put into designing the integration themselves.

------------------------------
Wayne Schulz
wayne@s-consult.com
Schulz Consulting
(860) 516-8990
CT
------------------------------

Agreed with Jerry and Wayne. My response is more of a blanket statement for any solution that isn't already in the Sage 100 ecosystem as an ISV than to Housecall Pro specifically.

What I've learned in integrating Sage 100 with other CRM applications is that people make a lot of false assumptions. They fall into several traps. The first trap being blankly stating "Yeah, we integrate with Sage," completely oblivious to the fact that "Sage" means a dozen things to us. So... we get the pleasure of navigating very sticky waters only to arrive at the point of, "we just need [solution] to create a [transaction in module] when [condition] happens." There will be a handful of them.

Additionally important - which side of the integration equation brokers/initiates the transaction. People fall into an assumption trap. Just because you have two softwares that can talk to eachother doesn't mean that they a) speak the same language (data types, JSON vs. flat file, etc.), or b) do a good job at informing one another that a transaction occurred. Meaning that a) there could be elements of data transformation required to ensure successful communication and no data corruption and b) the concept of when a trigger happens for one system to notify the other that something has changed.

Once they clarify the integration requirements, validate that integration pathways (VI / API-based / IPaaS), and finalize which side owns the communication of when the data gets exchanged... they'll have the full picture of executing on an integrated solution.

VI will be the less intensive to execute as there's usually less frequent transactions and therefore less frequent points of failure. There's usually only professional services fees unless a middleware is required to execute the VI project's scope.
API-based communication (there's lots of solutions: Sage 100 REST API (by Phil and me), ROI's Insynch, etc.) will be more appealing to modern-day integration builders; however, introduces additional licensing costs.

Hope that helps.

------------------------------
Best Regards,

Basil Malik
President/CEO
e: basil@malik-inc.com
------------------------------