Marketing automation RFP questions to ask before you choose a partner
Mautic has no paid edition, so the license line on a proposal is zero and the partner's scope is the main cost variable. The questions that separate a partner who can run Mautic in production from one who can only install it are about what happens after the first send: how sending domains are authenticated, how unsubscribes and consent records are written and honored across every channel, how the CRM sync handles duplicates, how cron jobs and queue workers are sized and monitored, how contacts are migrated with their consent history, and how upgrades are planned against Mautic's published support windows. Ask each partner to answer every question in writing, with the specific settings, tools and roles they would use. A vague answer such as "we handle deliverability" is a finding, not a yes.
Run the evaluation in two stages. First, collect written responses to a fixed question set and compare them side by side, including who on the partner's team owns each area and how escalations work. Second, ask for a scoped walkthrough of one real campaign from your own list, covering a segment, an email, a suppression check, a CRM update and the reporting you would receive. Ask the partner to show where each step is logged and how you would verify it. Before you compare quotes, confirm that every answer maps to a line in a written scope, because an answer with no matching deliverable is a cost you will discover later. DeployOpen does not publish prices. Quotes follow from the written scope, so the useful comparison is which partner's scope covers the operational work you need, and what each one leaves to your team.
Which questions to ask about sending, consent, sync and upgrades
How should a partner set up hosting and installation for self-hosted Mautic?
A credible partner will say Mautic runs on a dedicated server or VPS in your own cloud account or data center, not on shared hosting, because the Mautic project advises against shared hosting. Ask which PHP version they will target (Mautic 7.0 supports PHP 8.2, 8.3, 8.4 or 8.5), which database they will use (MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher), and whether they install from the production package or with Composer's recommended project template. Ask for the written architecture, the build steps and a documented restore test before go-live.
What does a partner configure for Mautic email sending and deliverability?
Expect the partner to name the sending service, the sending domain and the DNS records they will publish: SPF, DKIM and DMARC for the sending domain, plus a bounce and complaint handling path back into Mautic. Ask how they will warm up the domain, how they will monitor bounces and complaints, and who owns the DNS zone and the sending account after handover. Ask for a list of every DNS record they changed and a dated test report showing authentication results on sample messages.
How does a partner handle consent capture, unsubscribes and suppression in Mautic?
A good answer explains that consent and unsubscribe status are stored on the contact record, that unsubscribes and bounces are honored across every segment and campaign, and that suppression is applied before any send. Ask how consent sources and timestamps are recorded, how a withdrawal propagates to connected CRM and email tools, and how the one-click unsubscribe header is configured. Ask for a test plan that proves a suppressed contact cannot receive a campaign, and for a description of who decides the lawful basis, which remains your decision.
How does CRM sync work between Mautic and Salesforce or HubSpot?
The partner should name the connector they will use, the Mautic plugin for your CRM, and the direction of sync for each field, such as contact fields, owner, lifecycle stage and consent status. Ask which system is the source of truth for each field, how duplicates are matched, and what happens when both systems change the same record. Ask for a field mapping document, the sync frequency, the error log location and a test with sample records before production use.
How are cron jobs and queues sized for a self-hosted Mautic instance?
Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and the project advises staggering them. Expect the partner to list each scheduled command, its interval, and the broadcast command for segment emails. They should also say whether a messenger consumer runs as a supervised service when email is queued, and how queue backlog and failed jobs are monitored. Ask how they sized the server for your contact count and send volume, and what load test they ran before launch. Ask them to show the crontab and service configuration in writing.
How should contacts be migrated from an existing marketing platform into Mautic?
A credible partner will start with a data inventory: which fields, consent records, tags, segments and campaign history are in scope, and which can be left behind. They should describe a staged import with deduplication rules, field mapping, validation counts before and after each run, and a rollback plan. Ask how consent evidence is carried over, since a list without a consent record may not be usable. Ask for the migration plan, the reconciliation report and the owner who signs off each stage.
How does a partner plan Mautic upgrades and security patching?
Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, so the partner should describe a patch cadence and a test environment for each upgrade. Ask which version you will run and its support end date: Mautic 7.2 receives active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Ask for the upgrade runbook, the rollback method and the support window they will commit to in writing.
What evidence should a partner hand over at the end of a Mautic engagement?
Ask for a written handover pack that includes the architecture diagram, DNS and sending configuration, the cron and queue setup, the consent and unsubscribe test results, the CRM field mapping, the migration reconciliation and the upgrade runbook. Ask how access to servers, the database and the sending account is granted and recorded, and who keeps the credentials after handover. Confirm whether the partner offers ongoing support as a retainer, and which items you would maintain in-house. DeployOpen prepares this evidence but does not issue audit reports or certifications.
How hosting and operating models change the questions
In this model, the partner builds and runs Mautic inside an account or data center that you own and control. Your organization keeps the contract, the account ownership and the data, while the partner holds operational access for a defined scope. Questions focus on how that access is granted, logged and removed, and on who answers when a server or queue fails at night.
- Server access: Ask which named roles hold shell, database and cloud console access, how that access is approved, whether sessions are recorded, and how access is revoked at the end of the engagement.
- Data location: Ask where the MySQL or MariaDB database, the file storage and the backups reside, and which regions and accounts hold copies of contact data.
- Security patches: Ask who applies operating system, PHP and Mautic patches, how often the partner checks the Mautic release line, and who approves a patch before it reaches production.
- Hosting baseline: Confirm the partner will deploy on a VPS or dedicated server, not shared hosting. The Mautic project states that shared hosting is unsuitable and recommends a VPS or dedicated server.
- Exit terms: Ask how credentials, backups and configuration are handed back if the contract ends.
Confirm these answers in writing before award, because they determine what your security and compliance teams will be asked to evidence later.
Here your own platform or marketing operations team runs Mautic day to day, and the partner supports it through defined work such as upgrades, troubleshooting, integration changes and periodic reviews. Server access sits with your staff, so the questions shift from what the partner does to what your team needs to be able to do, and how the partner supports that work without holding standing privileges.
- Access split: Ask which tasks the partner performs with temporary access, which tasks stay with your staff, and how that split is written into the support agreement.
- Runbooks and handover: Ask for written runbooks covering cron job monitoring, queue workers, failed sends and restores, and for a walkthrough with the staff who will run them.
- Patch ownership: Ask who tracks Mautic's monthly patch releases and minor releases, who tests them in a staging copy, and what the partner will review before your team applies them.
- Skills coverage: Ask how many of your people the partner will train, and whether that training covers PHP runtime management and cron scheduling.
- Support boundaries: Ask which incidents the partner responds to, through which channel, and whether support covers only Mautic or also the mail server and CRM connectors.
Check that your staff can perform each task without the partner present, because that is the test of whether this model works.
A managed provider runs Mautic on infrastructure it operates, sometimes in its own account and sometimes in a hosting arrangement you contract separately. The Mautic project separately promotes managed and hosted services alongside the free self-hosted download, so a managed offer is a distinct commercial choice, not the same as running Mautic yourself. The key questions concern where data physically lives and which legal entity can access it.
- Data location: Ask for the country and facility where contact data, logs and backups are stored, and whether any copies leave that jurisdiction, including for support or failover.
- Access by the provider: Ask which provider staff can read contact records, how that access is logged, and whether your organization can review those logs.
- Patch responsibility: Ask which Mautic release line the provider runs, how quickly it applies security releases, and whether you receive notice before an upgrade that changes behavior.
- Customization limits: Ask whether custom plugins, CRM connectors and cron schedules are allowed, and what the provider charges for each change.
- Portability: Ask for a full export of contacts, consent records, segments and templates, and confirm the format and the timeline for that export.
Confirm that your legal and procurement teams have reviewed the data processing terms before you compare pricing, because the hosting location and access rules often decide the outcome.
Partner answers that should stop the shortlist
Most weak marketing automation proposals sound confident at first reading. The answers below look reasonable in a slide deck but fail once sending, consent, scheduling or upgrades meet real volume. Each card names one answer pattern and the question that exposes it.
Promised inbox placement without DNS work
A partner who guarantees inbox placement before reviewing your sending domains is describing a result they do not control. Mailbox providers judge authentication, complaint rates, bounce handling and sending history, and none of these is fixed by the software. Ask for the SPF, DKIM and DMARC records they will publish, the dedicated sending domain plan, the warm-up schedule, and who owns complaint monitoring after go-live.
Sending from shared hosting
The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server instead. A proposal that places the application, queue or cron jobs on a shared plan will struggle with scheduled jobs and email throughput, and it weakens access control. Ask which hosting model they propose, how the server is isolated, and what the platform looks like in the reference architecture.
No written consent record model
If a partner cannot show how consent is captured, timestamped, stored and withdrawn, the unsubscribe link is the only control, and that does not satisfy a records question. Ask where the consent source, date and wording are kept for each contact, how suppression applies across segments and imports, and how an erasure or objection request reaches every connected system. The answer should be a documented model, not a verbal assurance.
Cron run as one unstaggered job
Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and its documentation says these should be staggered. A single job that runs everything at once will overlap, slow the database and delay sends. Ask for the schedule of each cron task, the messenger consumer setup for queued email, how overlapping runs are prevented, and how they will monitor job failures.
Migration without a deduplication plan
Importing several lists, CRM exports and event sign-up files into one database creates duplicate contacts, conflicting consent flags and inflated send counts. A partner who starts the import before agreeing on matching keys and survivorship rules will carry those errors into every campaign. Ask how they match records, which source wins for consent and opt-outs, how they keep a migration log, and how they reconcile counts before the first send.
Unsupported Mautic versions for production
Support windows for Mautic releases end on fixed dates, and a proposal built on a version past its security support period leaves production exposed. The release page also identifies a long-term support line for later planning. Ask which version they recommend, the date its security support ends, how minor and patch releases will be applied in a staging environment, and who signs off each upgrade.
How to run the evaluation in four rounds
The sequence moves from written answers to a live look at the platform and then to a fixed-scope proposal, so each round tests a claim the previous round could not. By the end, the buyer knows who will run Mautic, how sending and consent work in practice, and what is included in the price.
Send the written question set
Marketing operations sends the full question set to every shortlisted partner, with a request for a named architecture, a sample runbook for sending and deliverability setup, and a sample runbook for cron and queue sizing. Security and the CRM owner review the questions that touch their areas before issue, so the set is complete on the first pass. The round is done when each partner has confirmed receipt and a named technical lead who will answer follow-up questions.
Score the written answers
Each reviewer scores the written answers against the same criteria, separately, before the group meets. Marketing operations scores segmentation, campaigns and contact migration, security scores consent records, unsubscribe handling, and hosting, and the CRM owner scores sync direction, field mapping and duplicate handling. Vague answers, such as a claim that a feature is supported without a configuration example, are flagged for a direct question in the demo. The round closes when the group agrees on a short list and a written list of open questions.
Run a scoped demo of segments and campaigns
Ask the shortlisted partners to build a small, scripted scenario in a test instance: one segment based on field values, one campaign with a wait step and a decision branch, and one unsubscribe and preference change that must be honored by the next send. Marketing operations drives the scenario, and the security lead watches the consent record and audit log for each action. The round is complete when the scenario runs without manual database edits and the team can explain every step the partner took.
Test send to seed addresses
Send a test campaign to a set of seed addresses across major mailbox providers, and check headers for SPF, DKIM and DMARC alignment, inbox placement and the unsubscribe link. Ask the partner to show the queue and cron settings used for the send and how the send would scale to the buyer's real list size. The deliverability lead records results per provider. The round is done when the team has a documented test result and the partner has explained any gap in writing.
Request a fixed-scope proposal with assumptions
Ask the partners that passed the first four rounds for a fixed-scope proposal that lists deliverables, the environment in which the work will run, the CRM sync rules, the migration plan, and the upgrade approach for the Mautic release line chosen. Each proposal should state its assumptions, such as who provides the sending domain, the email service, and CRM access, and what would change the price or timeline. The buyer confirms that each assumption is one they can meet. The round is complete when the proposals can be compared line by line.
How to score partner responses
This table compares what a strong, partial and weak partner answer looks like for each part of a Mautic RFP. Weights are a suggested starting point you set for your own risk profile, not a fixed standard. Read the score meaning column first, then check whether each answer names a concrete artifact you can inspect.
| Question area | Suggested weight | Evidence required | Strong, partial and weak answers |
|---|---|---|---|
| Hosting and environment | High | Architecture diagram, server sizing rationale, confirmation the host is a VPS or dedicated server, not shared hosting | Strong: names the hosting model, PHP and database versions, and separation of web, worker and database tiers. Partial: names a host without sizing logic. Weak: proposes shared hosting or cannot state versions. |
| Sending and deliverability | High | Sample SPF, DKIM and DMARC records for your domain, bounce and complaint handling design, sending service choice | Strong: explains domain authentication setup, warm-up approach, and how bounces feed suppression. Partial: lists records without monitoring. Weak: says deliverability is handled by the email provider. |
| Consent and unsubscribe | High | Sample consent capture flow, unsubscribe and preference-center behavior, record of how withdrawals are logged | Strong: shows where consent is stored, how withdrawal blocks all future sends, and who signs off the lawful basis. Partial: describes an unsubscribe link only. Weak: treats consent as a checkbox with no records. |
| CRM sync | Medium | Field mapping sheet, sync direction per object, duplicate-matching rules, error and retry handling | Strong: defines a system of record per field, duplicate rules and a reconciliation report. Partial: names the connector without field mapping. Weak: promises two-way sync with no conflict rules. |
| Cron jobs and queues | Medium | Cron schedule with staggered timings, messenger consumer setup, sizing notes tied to contact count and send volume | Strong: lists each cron job and the queue worker, states what is monitored and how backlog triggers action. Partial: lists jobs without sizing. Weak: says capacity can be added later. |
| Contact migration | Medium | Migration plan with field mapping, consent carry-over method, dedupe and validation steps, rollback point | Strong: carries consent evidence across with each contact, runs a test import, and keeps a rollback copy. Partial: imports contacts without consent history. Weak: imports the full list without validation. |
| LTS upgrades | Medium | Upgrade calendar tied to published support windows, test environment plan, rollback procedure | Strong: plans to a long-term support release and documents support end dates from the vendor's release page. Partial: upgrades on request. Weak: runs an unsupported version or says upgrades are unscheduled. |
| Support and ownership | Medium | Support hours, named escalation path, backup and restore test records, documentation handover | Strong: defines who patches, who monitors and how restores are tested. Partial: offers support without response targets. Weak: no clear owner after go-live. |
How LTS upgrades and support windows shape the contract
Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and each line carries its own support window. Those windows, not the release date, decide when a version stops receiving security fixes. The Mautic releases page lists Mautic 7.2 (Absolunto) with active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. A partner's upgrade plan should be tied to those dates, so your instance is not left on a line that has already lost security coverage. Confirm the current dates on the Mautic releases page before the contract is signed, because the schedule can change.
Ask the partner how they plan the move onto an LTS line. A credible answer names the current version in your environment, the target version, the PHP and database requirements that change between them, and the custom plugins, themes and CRM connectors that must be retested. Ask who owns each step: the partner's engineers, your administrators, or a vendor of a connector. Ask how staging tests run: whether staging is a copy of production data with personal data masked, how long the test cycle lasts, which campaigns, segments, cron jobs and email sends are checked, and who signs off before production. Ask whether a rollback path is documented for the database and the file system, not only for the code.
Finally, ask whether upgrades are in scope of the retainer or priced separately. Some partners include patch releases and charge a fixed fee for each major or LTS move. Others bundle everything. Ask the partner to show, in writing, what is one-time (the initial migration to an LTS line) and what recurs (patch application, monitoring, security reviews of new releases). Ask what triggers a quote for an out-of-cycle upgrade, such as a security advisory, and what the response expectation is for each. Your contract should name the Mautic version it covers and the date after which the partner will move you to the next supported line.
What buyers ask before hiring outside help for Mautic
What drives the cost of a Mautic implementation?
The cost follows the written scope, so the main drivers are how many systems Mautic must connect to, how many contacts and sending domains are involved, and how much existing data must move in. Mautic itself has no paid edition, so the spend goes to people and infrastructure: setup and configuration, CRM integration, email sending service, server hosting, migration of contacts and history, and testing. Each item rises with complexity, such as a CRM with custom objects, several brands on one instance, or consent records that must be rebuilt rather than imported. Ask for a quote that lists each component separately, with the assumptions behind the contact count, number of integrations and sending domains.
Which costs are one-time and which recur every year?
One-time costs usually include scoping, installation, configuration, deliverability setup, CRM integration, migration and staff training. Recurring costs include hosting, the email sending service, backups, monitoring, security patching, minor and major upgrades, and any support retainer. Upgrades deserve their own line because the Mautic project publishes monthly patch releases, minor releases every three months and major releases every two years, so some work recurs on a predictable schedule. Ask the provider to separate one-time fees from monthly or annual run costs, and to state which hosting and sending charges are billed directly by your cloud or email provider.
Can our own team run Mautic without an outside partner?
Yes, many teams run Mautic in-house, but the work is operational as well as marketing. Mautic is PHP on the Symfony framework, depends on cron jobs for segment updates, campaign updates and triggers, and needs a messenger consumer when emails are queued. Your team needs someone who can manage a Linux server, a database, mail authentication and scheduled jobs, as well as a marketing owner who builds campaigns. Mautic should not run on shared hosting, so a VPS or dedicated server is part of the plan. Ask a potential partner which of these tasks they would hand over, and which they would keep on a retainer.
What does our team have to provide for an implementation?
The work depends on access and decisions from your side, more than on technical effort alone. Expect to provide DNS access to publish SPF, DKIM and DMARC records for sending domains, administrator access to the CRM for the sync configuration, and a named data owner who can approve field mappings, consent sources and suppression rules. Legal or compliance staff should confirm the consent wording and unsubscribe handling before go-live. Your team also needs to agree who approves campaigns and who receives alerts from cron failures or bounce spikes. Ask the partner for a written responsibilities matrix before the scope is signed.
How long does a fixed-scope Mautic rollout usually take?
The timeline depends on the number of integrations, the state of the source data, and how quickly your team makes decisions, so ask for the duration in the written scope rather than relying on a general figure. The phases typically include discovery, environment build, sending and DNS setup, CRM sync testing, migration rehearsals, a controlled first send and handover. Delays most often come from slow DNS changes, unresolved consent questions, or contact data that needs cleaning before import. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask which milestones depend on client input and what happens if they slip.
What happens to our instance when Mautic releases an upgrade?
Upgrades are planned around the Mautic release schedule, which places security support windows on specific versions. For example, Mautic 7.2 receives active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. A good upgrade plan covers a staging copy of the database and files, a check of PHP and database version requirements, testing of campaigns, segments, cron jobs and CRM sync, and a rollback path. Ask the provider how they track version support dates, how often they patch, and whether upgrades are included in a retainer or quoted separately.
Who is responsible when a Mautic send fails or a sync breaks?
Responsibility should be written down before go-live, because failures can come from the server, the sending service, DNS, the CRM or the campaign logic. Ask the partner how monitoring covers cron job health, queue backlogs, bounce and complaint rates, and CRM sync errors, and who is alerted at each level. Confirm the response expectations in the contract, including whether they are measured against business hours, and whether they are covered by a support retainer. Clarify who can pause a campaign, who holds the backups, and how a restore is tested.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Mautic evaluations, that means turning RFP answers on sending, consent, CRM sync, queue sizing and migration into a written scope that your team can test before any production contact data moves.
How we scope
- Written scope covers sending domains, SPF, DKIM and DMARC setup, and the sending service you choose.
- Scope lists consent capture, unsubscribe handling and suppression rules agreed with your legal or compliance owner.
- Scope names the CRM objects, sync direction and integration method for each system in your stack.
How we build
- Mautic is installed in your cloud account, data center or air-gapped network, on hosts sized to your contact volume.
- Cron jobs for segments, campaigns and triggers are staggered, and the messenger consumer for queued email is configured and monitored.
- Test contact migration runs in a non-production environment, with reconciliation reports before any live import.
How we hand over
- Documentation covers configuration, cron and queue settings, sending architecture and the runbook for bounces and complaints.
- Your administrators receive training on segments, campaigns, consent records and the unsubscribe workflow.
- Upgrade plan follows Mautic's published release cadence and support windows, so your team knows which version carries security support.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to your written scope.
- Security testing of the Mautic deployment and its integrations can be scoped alongside the implementation.
