Why B2B lead scoring with Mautic is a data ownership decision before it is a tooling decision
Scoring and CRM sync succeed or fail on three things: the rules that decide whether two records are the same person or company, which system owns each field, and a shared definition of what a qualified lead is. The CRM choice matters less than those rules, and in most B2B teams the right CRM is the one sales already works in. Moving lead management from a hosted tool into self-hosted Mautic does not change that. It only makes the ownership questions unavoidable, because nobody else in the stack will answer them for you. Mautic is licensed under GPL-3.0 and has no paid edition of the software itself, so the license fee is zero. The money and the risk sit elsewhere: servers, email sending, integration work, and the ongoing administration that keeps scoring jobs and sync running. Mautic should not run on shared hosting, and the project recommends a VPS or dedicated server. Confirm with your hosting provider and your own platform team who patches the operating system, the PHP runtime and the database, and who is on call when a cron job stops.
Before you build any scoring model, write down the identity rules, the field owners and the lead stages. Decide which system creates a contact, which one may overwrite job title or company, and how a duplicate is merged when sales and marketing hold different records. Agree the score thresholds and the stage that hands a lead to sales with the sales leader, not only with marketing operations. These decisions are inexpensive to make early and expensive to unwind after thousands of records have synced in both directions.
Which requirements shape lead scoring and CRM sync
This table compares the Mautic runtime, scheduling, CRM connector and identity requirements that decide how scores, stages and CRM records behave in production. Read each row as a build input: the right-hand column names what to confirm with the vendor, plugin author or your own environment before the design is fixed.
| Requirement | What it means for the build | What to confirm |
|---|---|---|
| PHP and database versions | Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5 and MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Scoring tables grow with every point-earning event, so database sizing matters early. | Confirm the exact PHP and database versions for your chosen release and the storage plan for event and contact history tables. |
| Supported Mautic release line | Mautic 7.2 receives active and security support until 30 September 2026. Mautic 7.3 is planned as the long-term support release, with security support through 31 December 2027. | Confirm which line you will standardize on and the upgrade path to 7.3 before scoring rules and custom fields are locked in. |
| Cron jobs for segments, campaigns and triggers | Segment membership, campaign progression and campaign triggers run on cron. Scoring rules that depend on segments or campaign steps only update as often as these jobs run, and the jobs should be staggered. | Confirm the schedule, runtime per job and how a missed run is detected and recovered. |
| Broadcasts command and messenger consumer | The broadcasts command sends segment emails, and a messenger consumer is needed when email is queued. Without a running consumer, queued sends and follow-up stage changes can stall silently. | Confirm the process manager, restart policy and alerting for the consumer and the queue backlog. |
| CRM plugin behavior | The Mautic Salesforce and HubSpot plugins sync contacts and fields on their own schedules and field mappings. Direction of sync, which system owns each field and how conflicts resolve must be decided per field. | Confirm with the plugin documentation for your version which objects sync, the sync direction and the conflict behavior for each field. |
| Consent and suppression in the CRM | Unsubscribe, do-not-contact and consent status must reach the CRM as fields that sales can see and that block outreach. A score or stage change should never override a suppression flag. | Confirm the consent field mapping, who may change it, and whether suppressed contacts are excluded from CRM sequences and exports. |
| Single identity key for contacts and companies | Contacts and accounts need one stable key, such as a CRM record ID stored in Mautic, plus a rule for matching by email and domain. Without it, the same buyer appears as several contacts and scores split across them. | Confirm the matching order (ID, email, domain), how merges are handled and who approves a merge in each system. |
| Reporting fields and time sources | Score history, stage dates and CRM opportunity dates must be written in the same time zone and recorded at the same event. Mismatched timestamps make funnel and attribution reports disagree. | Confirm the time zone standard, which system stores the authoritative stage date and how backfills are labeled. |
Which CRM pairs with Mautic for B2B sync and why
Mautic can sync contacts, companies and activity with several CRMs, but the right pairing depends on where your sales team already works and where you want customer records to live. The cards below compare the two documented Mautic CRM plugins with two self-hosted or self-deployable CRM options, and name the trade-off each one puts on your team.
Salesforce through the Mautic plugin
Salesforce is the default choice when sales operations already runs its pipeline, territories and forecasting there. Mautic documents a Salesforce plugin, so the sync design is a configuration and field mapping exercise rather than custom code, but it still needs an owner for lead status, campaign membership and duplicate rules on both sides. Before you commit, confirm the plugin version, the objects it reads and writes, and which custom fields it supports for your Salesforce edition. Ask who maintains the connector after go-live.
HubSpot CRM through the Mautic plugin
HubSpot CRM suits teams that want marketing and sales records in one vendor's data model and already use HubSpot forms or the sales inbox. Mautic documents a HubSpot plugin, which lets you map contacts and activity between the two systems, but field support and sync direction must be confirmed for your plugin version before you design scoring around them. Check which property types map cleanly, how deleted or merged contacts propagate, and whether company association is supported. Expect to keep two systems of engagement data unless you decide one is the system of record.
SuiteCRM 8 for one infrastructure
SuiteCRM 8 is licensed under AGPL-3.0 and can run in the same infrastructure as Mautic, so customer and campaign data never leaves your network. The trade-off is that you own the CRM upgrade path, and SuiteCRM 8.10.2 is the current minor line, while 7.15 is an extended support release with security fixes until January 2028. SAML and LDAP login work, but SuiteCRM's SAML implementation does not support IdP-initiated logout, so ending a session at the identity provider does not end the SuiteCRM session. Plan that gap into your access review.
Odoo CRM and its licensing limits
Odoo CRM is attractive when you also run quoting, invoicing or inventory in the same suite, because lead, account and order data share one database. The Community edition is licensed under LGPL-3.0, but on-premise Enterprise use, the upgrade service and external API access depend on the Enterprise subscription or the Custom plan, which is the only plan listing external API access. Confirm whether your Mautic sync needs that API before you choose the edition. Also confirm which Odoo version your support window covers, because standard support runs only three years after each major release.
How to set Mautic points and stages so scores mean the same thing to sales
Agree the scoring definitions in writing before anyone builds a point rule. Sales and marketing should sign off on three things: which firmographic attributes count as fit (industry, company size, region, job function, existing customer status), which behaviors count as engagement (pricing page visits, demo requests, repeated email clicks, event attendance), and the score at which a contact becomes a marketing qualified lead and then a sales handoff. Write the thresholds as numbers in a shared document, and record who approved each one. In Mautic, fit and engagement are usually kept as separate point actions and campaign conditions, so a contact can be high in engagement and still fail the fit test. Decide early whether fit and engagement are added into one number or compared against two thresholds, because that choice determines what the sales team sees in the CRM.
Decide the decay and roll-up rules at the same meeting. Decay reduces points for stale activity, so a contact who was active two years ago does not look like a hot lead today; agree the rule, its time window and which actions it applies to, and confirm how Mautic's version handles it, since the configuration differs by release. Company-level scores are a separate decision: confirm whether a company score is the sum of its contacts, the highest single contact, or a count of engaged contacts, and state how contacts without a company record are treated. Then check the timing. Mautic relies on cron jobs for segment updates, campaign updates and campaign triggers, and the Mautic cron jobs documentation says these jobs should be staggered. If a job fails or runs late, stages and handoff triggers lag behind the activity that should have caused them, so sales will see stale scores. Assign an owner for cron monitoring and test the lag with sample contacts before go-live.
How a B2B sync rollout moves from data audit to live reporting
This sequence takes lead scoring and CRM sync from an agreed data model to a live Mautic setup that sales and marketing read from the same numbers. Each phase closes with a signed document or a working artifact, so no stage goes live on assumptions.
Audit data and sign off field mapping
Sales operations and marketing jointly inventory the lead, contact and company fields in Mautic and the target CRM, then agree which system owns each field, how lifecycle stages map to each other, and which behaviors earn score points. DeployOpen facilitates the workshops and drafts the field map. Done means a signed field mapping and scoring rulebook, with an owner named for every field that both systems can write to.
Build the Mautic host and database
The platform team provisions a VPS or dedicated server, since the Mautic project advises against shared hosting, then installs the Mautic release chosen for the support window the client needs, with the PHP version and MySQL or MariaDB settings that release requires. Cron entries for segment updates, campaign updates and triggers are staggered from the start. Done means a documented build record with versions, host configuration and a passing smoke test on the staging URL.
Build and test the sync on a staging CRM
Engineers configure the Mautic integration plugin for the chosen CRM, whether Salesforce, HubSpot CRM, SuiteCRM or Odoo, and map fields according to the signed document. Test records cover creates, updates, deletes and conflicting edits from both sides. Done means a test log showing each mapped field passes in both directions, plus a list of known limits, such as sync frequency and fields that cannot be written back, that the business has accepted in writing.
Clean duplicates and migrate contacts
Before production load, the team runs duplicate detection on contacts and companies, merges records with an agreed survivorship rule, and imports the cleaned set into Mautic with consent and suppression status carried across. Import logs are kept for each batch. Done means a reconciliation report showing source counts, imported counts, rejected rows and the duplicates resolved, signed by the data owner.
Run the scoring pilot on a limited segment
Scoring rules are switched on for one defined segment, such as a single region or product line, and sales reviews a sample of scored leads against their own judgment each week. The team adjusts point values and thresholds where scores do not match what reps see. Done means a pilot review record listing the rule changes made, the accepted thresholds and the sales sign-off on the handoff criteria.
Cut over with queue and cron monitoring
The team switches the full contact base to the live sync and scoring rules, with monitoring on cron job runs, the broadcast and messenger queues, and sync error logs. A rollback plan and named on-call contacts are rehearsed before the switch. Done means a cutover checklist with monitoring alerts confirmed, a rollback test result, and a short period of watched operation with no unresolved sync errors.
Hand over joint reporting and runbooks
Sales and marketing agree on one dashboard definition for lead volume, score distribution, stage conversion and pipeline sourced by campaigns, then the team delivers runbooks for sync troubleshooting, upgrades and field changes. Any ongoing support or upgrade work is scoped separately. Done means a signed reporting definition document, the runbook set and a recorded walkthrough for the owners who will maintain the system.
Evidence that the sync and scoring design can show an auditor
This table lists the records a lead scoring and CRM sync design should produce, the component that generates each one, and what an assessor will look for. DeployOpen prepares this evidence during implementation, but independent auditors assess it, so the goal is records that show what the design does and when it changed.
| Evidence | Produced by | What an assessor checks |
|---|---|---|
| Field mapping document | Mautic field definitions and the chosen CRM sync plugin or integration layer | Every field that moves between Mautic and the CRM, its direction, its owner and the agreed rule when both systems hold a value |
| Consent and suppression fields in the CRM | Mautic contact consent and do-not-contact fields, mapped to matching CRM fields | Whether opt-outs and suppression status reach the CRM and block sales outreach, not only marketing sends |
| Sync logs | Mautic integration logs and the CRM API activity or audit trail | Failed and skipped records, retry handling and a sample reconciliation showing matched contact and account counts |
| Scoring rule change records | Version control or a change log for Mautic points, stages and segment rules | Who changed a rule, when, why, and which leads were affected by each change |
| Duplicate handling rules and results | Mautic deduplication settings and CRM matching rules, with periodic merge reports | How contacts are matched to existing company and person records, and how duplicates found after sync are resolved |
| Backup and restore test results on staging | Backup jobs for the Mautic database and files, and the staging restore runbook | A dated restore into staging, the time it took, and a check that contacts, consent records and campaign history came back intact |
| Cron job monitoring records | Scheduler and job monitoring for segment updates, campaign triggers, broadcasts and the messenger consumer | Evidence that scheduled jobs ran on time, alerts for failed or stalled runs, and a record of who responds to them |
What teams ask before hiring help with B2B scoring and CRM sync
What drives the cost of B2B scoring and CRM sync work?
The main drivers are the number of systems to connect, how much duplicate data already exists, how far the CRM is customized, and where the platforms are hosted. Mautic itself has no paid edition, so the spend sits in servers, the email sending service, setup, CRM integration, data cleanup and ongoing administration. Each of these is paid to a different party: your hosting provider, your email provider, your CRM vendor or partner, and the implementation team. Ask for a quote that lists each system pair, the field mapping, the duplicate cleanup approach and the hosting assumptions separately, so you can see what recurs and what is one-time.
How long does a Mautic and CRM sync project usually take?
No fixed duration applies to every team, so treat any single number you see as unverified until it is tied to a written scope. Duration depends on how many CRM objects must sync, how clean your contact and company records are, whether scoring rules need agreement across sales and marketing, and whether a SuiteCRM 7 to 8 migration is part of the work. Most engagements are fixed-scope, so the timeline should be set in writing before work starts. Ask the partner which decisions must be made before build starts and which steps depend on your team's availability.
What does our internal team need to provide before the project starts?
Your team needs to supply four things: agreed definitions of a marketing qualified lead and a sales accepted lead, named data owners for contacts, companies and lifecycle stages, administrator access to the CRM and the Mautic instance, and a decision maker who can settle conflicts between sales and marketing rules. Without signed-off definitions, scoring points and stages will be rebuilt several times. Ask the partner to produce a short data dictionary and a sign-off list before any sync rule is built, so that the scoring model and the reporting use the same language.
Can our own team set up B2B lead scoring and CRM sync without a partner?
A capable in-house team can build parts of this, especially basic Mautic segments, points and campaigns, but sync rules and duplicate handling carry the most risk. Mautic depends on scheduled cron jobs for segment updates, campaign updates and campaign triggers, and it needs a messenger consumer when emails are queued, so someone must own that operations layer. The Mautic project also advises against shared hosting. Consider a partner for the CRM sync design, the data cleanup, and the handover of runbooks, and keep scoring rules in your own hands so that marketing can adjust them later.
How does a SuiteCRM 7 to 8 migration change the scoring and sync work?
SuiteCRM's documentation treats moving from version 7 to 8 as a migration, not an upgrade. A new SuiteCRM 8 environment is set up, the version 7 data is moved into it, and the version 7 instance must first be brought to the latest 7.14.x or later. The migration docs advise testing on a staging instance, backing up files and the database, and reviewing customizations, because the process may remove non-core files under the public/legacy folder. For lead scoring, this means field names, custom modules and sync mappings may need to be rebuilt and retested, so budget the sync design as part of the migration rather than as a later add-on.
How do we prevent duplicate contacts when Mautic and the CRM both create records?
Duplicates usually appear when two systems each create a contact without a shared matching rule. Agree one system of record for each object, define the matching keys (for example, email address plus company domain), and decide which system wins when fields conflict. Run a deduplication pass on existing data before the first sync, then monitor new duplicates after go-live. Ask the partner to show the exact matching logic, the merge rules, and how the sync handles records that were deleted or unsubscribed in one system but not the other.
Does DeployOpen handle the CRM integration and the reporting for both sales and marketing?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so CRM integration and the Mautic configuration fall within what it can scope. The reporting that sales and marketing agree on is defined in the written scope, including the lead definitions, the stage history and the source attribution. DeployOpen does not publish a price list, so ask for a quote that lists the integrations, the deliverables and the support arrangement, and confirm which CRM versions and sync directions are in scope before signing.
What should we confirm about Odoo or HubSpot before choosing the sync approach?
Confirm which Odoo edition and version you will run, because the Community edition has no access to the upgrade service, and the on-premise use of Enterprise requires a subscription. Odoo's standard support covers the first three years after a major release, and major upgrades are mandatory every two years on Odoo Online and Odoo.sh. For HubSpot and Salesforce, Mautic offers plugins, so confirm the plugin version, the supported sync direction and the API limits with the vendor and your partner before designing field mappings. Ask each vendor to confirm these points in writing.
What to ask an implementation partner about Mautic to CRM sync
Start with the matching key and merge rules, because every other part of the sync depends on them. Ask the partner which field Mautic and the CRM use to match a contact (email address, CRM contact ID, or a combination), how a record is created when no match exists, and who wins when both systems hold different values for the same field. Ask for the written rule set for each object, including company records and lead status, and ask how the partner tests duplicate creation with deliberately messy input such as mixed-case emails and alias addresses. Ask whether the sync writes to Mautic contact fields only or also overwrites CRM ownership and scoring fields, since that decision determines who can change a score.
Next, ask how cron and queue capacity is sized for scoring volume. Mautic relies on cron jobs for segment updates, campaign updates and campaign triggers, and the Mautic cron jobs documentation says these should be staggered. Ask the partner to show the schedule, the expected run time at your contact count, and how a delayed cron run would show up in the score. Ask whether a messenger consumer is running when email is queued, and how the partner would detect a stalled worker before sales notices stale scores. Request the sizing assumptions in writing so they can be checked against your own volumes.
Finally, ask how the sync is tested on staging before production and how plugin and CRM version changes are handled. Staging should use a copy of production data with personal data handled under your own rules, plus a replay of the field mapping and a count reconciliation between systems. Ask how the partner pins the Mautic HubSpot or Salesforce plugin version and the CRM version, what regression tests run after each update, and how a Mautic minor release or long-term support upgrade is scheduled around the sync. Ask for the rollback plan for each change. For SuiteCRM 8, confirm with the partner whether any upgrade is treated as a migration, as the SuiteCRM migration documentation describes for version 7 to 8 moves.
How DeployOpen scopes, builds and supports B2B sync on self-hosted Mautic
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so lead scoring and CRM sync can run on Mautic in your cloud account, data center or air-gapped network. We start with a written scope that agrees the scoring model, sync rules and reporting definitions before any build work begins.
How we scope
- Written scope covering scoring points, stages, company records and the Salesforce, HubSpot, SuiteCRM or Odoo sync direction for each object.
- Agreed rules for duplicate matching, field ownership and which system wins when both sales and marketing edit a contact.
- Shared definitions for a qualified lead, a sales-accepted lead and the reporting metrics both teams sign off before build starts.
How we build
- Mautic configuration for scoring, segments and campaigns, plus the cron and queue setup that keeps scores current on your hosting.
- Sync integration built and tested in a staging environment against sample records, including duplicate and conflict cases.
- Hardening of the Mautic host, access controls and authentication settings, with the integration tested before any production data moves.
How we hand over
- Written documentation of the scoring model, field mappings, sync schedule, duplicate rules and the reports agreed at scoping.
- Runbooks for administrators covering cron checks, plugin credentials, failed sync records and how to change a scoring point.
- Knowledge transfer sessions with marketing operations and CRM administrators, and an evidence pack for your internal or external reviewers.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, including Mautic and CRM version changes.
- Regular review of sync failures, duplicate growth and scoring drift against the definitions agreed at scoping.
- Retest of the integration after each CRM or Mautic upgrade, with changes documented so your team keeps an accurate record.
