How CURO Connected HubSpot and M-Power to Run Every Project From One System

• Ran full process discovery before touching HubSpot: We sat with CURO’s sales, design, production, delivery, and installation teams to map how each process actually worked, not how it was assumed to work. That gap became the blueprint for everything that followed.
• Split one pipeline into three: Design, Execution, and Strategic Agreements each got their own pipeline, with stages, ownership rules, and required fields built around how that specific type of work actually moves.
• Built a dedicated Installation Project object: Rather than cramming multi-location details onto the deal record, we created a custom object linked to the relevant Deal, Company, and Contact. It tracks installation location, planned date, assigned installer, dependencies, and completion status on its own, without cluttering the main deal.
• Connected HubSpot and M-Power with clear rules: We designed a bi-directional integration and set the Quote Required stage as the handoff point. Once a deal reaches that stage with the right information in place, HubSpot sends the project data to M-Power, and M-Power returns the Quote Number, Order ID, Job ID, and production and delivery updates.
• Defined ownership at the field level, not just the system level: HubSpot controls CRM activity, tasks, follow-ups, and installation coordination. M-Power controls quotations, orders, jobs, and production. Documenting this down to the individual field stopped either system from quietly overwriting information owned by the other.
• Automated more than 30 workflows: These workflows assign owners, create tasks, send internal notifications, update statuses, and flag delays automatically, so teams stop relying on memory to keep a deal moving forward.
• Locked in data governance from day one: Unique identifiers, duplicate-prevention rules, and error logging with retry handling were all built before automation went live, so the integration stayed reliable instead of quietly breaking under real use.

Implementation Challenges

Beyond CURO’s business problems, the build itself came with real technical hurdles.

• Getting the pipeline structure right: One pipeline for every project type would have made the CRM impossible to manage. Too many pipelines would have fragmented reporting and confused users. We landed on three: Design, Execution, and Strategic Agreements, and used properties and workflow branches to handle smaller variations within each one.
• Keeping 30+ workflows from firing on top of each other: With that many automations running across connected processes, the risk was duplicate tasks, repeated notifications, or conflicting property updates every time a record moved. We built careful enrolment criteria, controlled re-enrolment settings, and suppression rules so each workflow fired once and only when it should.
• Stopping the integration from looping on itself: A bi-directional sync between HubSpot and M-Power creates an obvious risk: an update from M-Power changes a HubSpot field, which triggers another update back to M-Power, and so on. We built source-system tracking and controlled update conditions into the integration logic so a change only flows one direction at a time.
• Matching records reliably across two systems: Without solid identifiers, the integration could easily create duplicate deals, installation projects, or orders instead of updating the right existing one. We used unique identifiers, stored M-Power reference IDs directly in HubSpot, and checked for existing records before creating anything new.
• Handling the sync failures that were bound to happen: Missing data, invalid values, and temporary connectivity issues will always break some synchronization attempts. We built error logging, clear failure reasons, and retry handling into the integration from the start, so a failed update gets flagged and reprocessed instead of quietly disappearing.
• Testing every route, not just the obvious one: CURO’s processes don’t all follow the same path. Testing had to cover Online Orders, Print & Deliver, Branch Rebrands, Supply & Installation, multi-location installs, missing information, and failed syncs separately, since a test plan built around one “standard” journey would have missed most of the real ones.