How to use this marketing automation requirements checklist
Write your requirements before you compare platforms. A team that must choose or build marketing automation inside its own infrastructure should first fix what the system has to do, how it must be secured, what it must connect to, how it will run and what evidence it must produce. This checklist covers those five areas: functional, security, integration, operational and compliance. Each requirement carries a verification method, such as a configuration review, a test send, a restore exercise or a document request to the vendor or partner, so that a claim becomes something you can check. The aim is a written requirement list that can be scored against any option, including a SaaS suite you may still consider.
*Mautic* is the reference platform in this hub, so several examples name its settings, cron jobs and queues. The requirements themselves are platform-neutral, and the same questions apply if you evaluate another tool. Turn the checklist into a written scope with a named owner for each line, a verification step, and a decision on whether the item is mandatory or a preference. Confirm the current Mautic version, PHP and database support against the Mautic requirements page before you fix a platform baseline, because support windows change between releases. Ask every bidder to map its answers to your list, so gaps show up before contracts are signed.
Which functional requirements a marketing automation platform must meet
This table lists the functional requirements a self-hosted marketing automation platform must meet, why each one matters and a concrete test you can run before committing. Use it as a scoring sheet during a proof of concept, and treat any requirement that fails its test as a scope item for the implementation partner.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Contacts and send volume | Database size and monthly send volume drive server sizing, queue load and sending service cost. | Import a sample file at your real record count, then run a segment build and a test send to a seed list at your expected batch size. |
| Consent capture | Each marketing contact needs a recorded opt-in or lawful basis, and withdrawals must take effect everywhere. | Submit a form with a consent checkbox, confirm the consent event is stored with a timestamp, then unsubscribe and confirm the contact is excluded from the next send. |
| Segments and campaigns | Segments must update on schedule, and campaigns must trigger from the right events without duplicate sends. | Create a segment from two fields, add a contact that matches, wait for the scheduled segment update, and confirm the contact enters the campaign once. |
| Landing pages and forms | Forms feed contacts, consent and campaign triggers, so field mapping errors create bad data from day one. | Publish a test landing page, submit it with a new and an existing email address, and check that fields, consent and duplicate handling behave as specified. |
| Tracking and cookies | Tracking scripts set cookies and may fire before consent is given, which creates legal and audit exposure. | Load a page in a clean browser profile, inspect cookies and network calls before and after consent, and record what fires in each state. |
| SPF, DKIM and DMARC | Mailbox providers use these records to decide whether mail reaches the inbox, and missing records cause rejection or spam placement. | Query the DNS records for the sending domain, send a test message, and review the authentication results in the message headers. |
| CRM sync | Two systems holding the same contact create duplicates and conflicting consent unless the sync rules are explicit. | Create, update and delete a contact in each system, then confirm the change appears once in the other system with the correct consent status. |
| Cron and queue capacity | Segment updates, campaign triggers and queued sends stop silently if scheduled jobs or the queue consumer fail. | Run the scheduled jobs at production frequency for a full day, then check job logs, queue depth and send timing against the schedule. |
| Single sign-on | Administrators need central access control, offboarding and audit trails tied to the corporate directory. | Sign in with a test identity from the directory, remove that identity, and confirm access to the platform is revoked on the next attempt. |
Security requirements that protect contact data and admin access
Marketing platforms hold personal data, consent history and privileged access to every sending domain and integration. The six controls below cover who can change what, how people sign in, how data is protected, how it is recovered and how the platform is kept current. Confirm each one against your own environment and the vendor's documentation before you commit to a design.
Access control and admin roles
Mautic has role-based permissions that decide who can edit segments, launch campaigns, export contacts and change configuration. Map each marketing role to the smallest set of permissions it needs, and keep a separate, rarely used administrator account for platform settings and plugin installs. Ask the implementation partner to document every role, who holds it, and how access is removed when people change teams. Confirm the permission matrix with your own marketing and security leads before go-live.
SSO and multi-factor authentication
Decide whether administrators sign in through your central identity provider or through local accounts, and whether multi-factor authentication is enforced for every privileged user. Local accounts left behind after an SSO rollout are a common gap, so list them and disable the ones you do not need. Check how the chosen Mautic version handles SSO and which identity protocols your setup supports, and test a failed login, a locked account and an offboarded user before launch. Confirm which sign-in methods the release you select supports.
Encryption in transit and at rest
Contact records, consent entries and CRM credentials move between browsers, the Mautic server, the database, the mail relay and connected CRMs. Require TLS on every public endpoint, including tracking pixels, landing pages and form posts, and confirm that database connections and backups are protected. Ask where API keys for the CRM and the sending service are stored and whether they are encrypted at rest. Confirm TLS versions, certificate management and key storage with your hosting team.
Backup and restore of contact data
Contact lists, segments, campaign history and consent records live in the database, while uploaded assets and configuration live on the file system. A backup is only useful after a restore has been tested, so schedule a restore into a separate environment and time how long it takes. Agree in writing how often backups run, where copies are kept, how long they are retained and who can restore them. Ask the partner to show a completed restore test, not only a backup job log.
Logging of consent and admin actions
Consent capture, unsubscribes, suppression changes and admin actions such as role edits, exports and campaign edits should leave a record that can be searched later. Confirm which events Mautic writes to its audit and contact timelines, which go to the server logs, and how long each is kept. Send these logs to a central store that administrators cannot quietly edit. Confirm with your compliance lead which events must be retained as evidence and for how long.
Patching under the support windows
Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and each version has its own support end date. Mautic 7.2 receives active and security support until 30 September 2026, while Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Choose a version that matches your upgrade capacity, plan a test environment for every upgrade, and write the patch cadence into your operating runbook. Confirm the support end date of the version you deploy before you sign the scope.
How cron jobs and queues set the capacity a platform needs
Mautic does much of its work through scheduled jobs, not in the request path, so cron and queue capacity decides whether campaigns run on time. The Mautic cron jobs documentation describes cron-driven processes for segment updates, campaign updates and campaign triggers, and advises that these jobs be staggered so they do not all start at once. Segment emails are handled by a broadcasts command, and when emails are queued, a messenger consumer has to be running to send them. If any of these stop, the symptom is not an error page. Contacts simply stop moving between segments, campaign steps fall behind, or messages sit in the queue.
For sizing, this means the server plan must account for background work as well as web traffic. The buyer should ask the partner to map each scheduled job to its frequency, expected run time and the contact count it touches, then confirm how many consumer processes are needed to drain the queue within the send window the business requires. Database load, PHP memory limits and the number of concurrent workers all trade against each other, so the sizing should be written down as a configuration baseline, not left to defaults. Confirm the supported PHP and database versions against the current Mautic requirements before fixing the host specification, since shared hosting is not supported.
Monitoring is the control most often missing. The partner should set up alerts for cron runs that fail or overlap, for consumer processes that exit, and for queue depth that keeps growing. Ask how failed jobs are logged, who receives the alert, and what the recovery runbook says. Finally, ask how capacity is tested against your actual send volume: whether a load test uses your contact counts and campaign mix, what results are recorded, and how the results are repeated after upgrades or new campaigns are added. Vague answers here usually mean the platform will be sized for the demo, not for your Monday morning send.
Integration requirements for CRM, identity and web properties
Mautic rarely works alone. Contacts, consent and campaign results have to move between the CRM, the identity provider, the website and the analytics stack, and each link needs a stated direction and an owner. The cards below cover the integration decisions to make before build starts and the test record to use for checking each one.
CRM sync direction and field mapping
Decide which system owns each contact field before any connector is configured: name, email, lifecycle stage, consent status and owner. Mautic offers CRM plugins for HubSpot and Salesforce, and the mapping should be written as a table that both marketing and sales sign off. Verify with one test contact: create it in the CRM, confirm it appears in Mautic with the right fields, change a field on each side, and check which change wins. Confirm the plugin version supports your CRM edition.
Duplicate contact handling
Set the matching key (usually email address) and decide what happens when a CRM record and a Mautic contact disagree on the same person. Without this rule, one buyer can appear as several contacts and receive the same campaign twice. Verify by creating a test record with an upper-case email and a trailing space, then importing a second copy from the CRM. Confirm that exactly one contact results and that its history is merged, not reset.
Identity provider login and roles
Decide whether administrators sign in through your identity provider (single sign-on) or through local accounts, and who maps to which Mautic role. Mautic's authentication documentation describes the supported methods for the version you deploy, so confirm the exact option against that version before design. Verify with three test users: an administrator, a campaign editor and a read-only analyst. Each should reach only the screens their role allows, and a disabled account should lose access on its next sign-in.
Website forms and landing pages
Decide which forms write to Mautic, which pages host them, and where consent checkboxes sit in relation to the submit button. Each form field should map to a contact field so consent wording and the time of consent are stored with the record. Verify by submitting a test form from a clean browser, then confirming the contact, its source page, the consent record and the first campaign trigger all appear in Mautic. Repeat with the consent box unchecked to confirm the contact is not marketed to.
Analytics and consent tools
Decide which analytics and tag manager scripts run on forms and landing pages, and which consent management platform controls them. Each tool that receives personal data needs a documented purpose and a switch that the consent platform can turn off. Verify with a browser session that rejects analytics consent: no third-party request should fire, and the Mautic tracking script should only run where your policy allows it. Record the result as evidence for the consent review.
Data export and exit path
Decide what must be exported on demand and on exit: contacts, consent history, unsubscribes, campaign membership and suppression lists. Export should include the consent records, not only email addresses, so a new system can honor withdrawals. Verify by exporting a test segment, loading it into a clean environment and confirming that a contact who unsubscribed stays suppressed. Ask the implementation partner how the export is scheduled and who holds the copies.
Operational requirements for upgrades, hosting and support
This table compares the operational requirements that keep a self-hosted Mautic instance running after launch: hosting, runtime versions, release cadence, support windows, backup, monitoring and upgrade ownership. Read each row as a question to answer before the build starts, and note the verification column for the evidence to request. The main takeaway is that Mautic upkeep is a recurring duty with a named owner, not a one-time installation.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Hosting type | The Mautic project says it should not run on shared hosting and recommends a VPS or dedicated server, so hosting choice sets the performance and control baseline. | Confirm the proposed VPS or dedicated server specification, and ask the partner to show the sizing assumptions for your contact volume. |
| PHP runtime | Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, and an unsupported PHP version blocks upgrades. | Check the PHP version on the running server against the Mautic requirements page for the release you deploy. |
| Database engine | Mautic 7.0 requires MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, so database choice affects migrations and backups. | Confirm the engine and version in the environment, and check that tables use InnoDB before the first import. |
| Web server | Apache, Nginx or IIS are the supported web servers for Mautic 7.0, and the choice shapes TLS, caching and tracking endpoint configuration. | Ask for the web server configuration and confirm which server the partner has tested with your chosen Mautic release. |
| Release cadence | Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, so upkeep is continuous. | Ask the partner for a written upgrade calendar that maps each release type to a test window and a production change. |
| Support windows | 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. | Check the Mautic releases page before go-live, and record the end-of-support date for the version you run. |
| Backup and restore | Upgrades and failed changes need a tested restore path covering the database, uploaded files and configuration, not only a snapshot. | Request a restore test result from a non-production copy, and confirm the recovery point and recovery time targets in writing. |
| Monitoring | Cron failures, queue backlogs and mail send errors can stop campaigns silently, so monitoring must cover jobs and the messenger consumer. | Ask which alerts cover cron job runs, queued email processing and bounce rates, and who receives them out of hours. |
| Named upgrade owner | Without a named person accountable for patches and minors, security fixes wait and the instance drifts out of support. | Confirm in the statement of work who owns each upgrade step, who approves production changes and who signs off the test results. |
What buyers ask before hiring a marketing automation implementation partner
What makes the total cost of a self-hosted Mautic project go up or down?
Mautic itself has no paid edition, so the cost is what you pay for people and infrastructure around it. The main components are a server or VPS sized for your contact base and send volume, an email sending service, the implementation work (installation, sending domain setup, consent configuration, segments and campaigns), CRM integration, data migration and ongoing administration. Setup is mostly one-time, while hosting, sending and administration recur. Cost rises with the number of integrations, the amount of history to migrate and the number of approval steps your legal team requires. Ask any partner for a quote that separates these components and states what is one-time and what recurs.
How long does a marketing automation rollout take, and what sets the timeline?
The timeline depends on scope, which is why DeployOpen agrees scope, deliverables and timelines in writing before work starts. The biggest variables are how many systems must sync with Mautic, how clean your contact data is, whether consent records must be rebuilt, and how long DNS changes and sending domain verification take on your side. Standard setup steps such as installing on a supported PHP and database version and configuring cron jobs are predictable, while integrations and approvals are usually the slow parts. Ask the partner to show the milestones and which of them depend on your team.
What does the work need from our team?
Expect to provide DNS access so the sending domain can be authenticated with SPF, DKIM and DMARC records, admin access to your CRM for the sync configuration, and a named owner for data decisions. Legal or compliance must sign off on consent wording, preference center text and the lawful basis for each list before any campaign sends. Your web team will also need to approve tracking and cookie changes on landing pages and forms. Agree these responsibilities in the scope document so delays are visible early.
Can an internal team run Mautic alone after the initial setup?
Yes, many teams operate Mautic in house once it is configured, but it requires someone who can maintain the server, monitor cron jobs and queues, and apply updates. The project publishes monthly patch releases, minor releases every three months and major releases every two years, and each version has a defined support window, so upgrades are recurring work. Confirm that your team can handle PHP and database requirements, staggered cron scheduling and a messenger consumer for queued email. A retainer with a partner can cover upgrades and monitoring if your team lacks capacity.
Should we choose a managed Mautic service or self-host it?
Choose self-hosting when you need control over where contact and tracking data lives, when internal policy restricts hosted SaaS, or when you want to avoid per-contact pricing. Choose a managed service when you lack server operations capacity and accept the provider's data location and terms. Mautic is not meant for shared hosting, so self-hosting means a VPS or dedicated server plus the operational work described above. Compare the two options on data location, who patches the software, who handles email reputation and what exit terms apply.
What should we ask for in a marketing automation quote?
Ask for a written scope listing each integration, the number of contacts and expected send volume, and the systems in scope for migration. Request separate line items for setup, CRM integration, sending domain configuration, consent and preference handling, training and post-launch support. Ask which components are one-time and which recur, what the handover includes and how upgrades to new Mautic versions are priced. Confirm what the partner will not do, such as issuing compliance attestations, which remain the role of independent auditors.
Which Mautic version and server requirements should we plan for?
Plan for a version that is still in support during your rollout and beyond. Mautic 7.2 supports PHP 8.2 to 8.5 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. Mautic 7.0 requires MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and a web server such as Apache, Nginx or IIS. Confirm current support dates on the Mautic releases page before you commit to a version.
Which questions separate one platform or partner from another
Most platforms and partners look alike on a feature list. Mautic, and most marketing suites, can send campaigns, score contacts, sync a CRM and host forms. The differences show up in how the work is handled when something goes wrong or when rules change: how consent is recorded, how unsubscribes and suppressions propagate, how bounces and complaints are processed, how duplicate contacts are merged in the CRM, and how upgrades are scheduled. Those answers decide whether your sending history will hold up under a regulator's or a mailbox provider's questions, so ask for them in writing before comparing feature sets.
Ask each vendor or partner to show, not describe, the following. First: where is a consent record stored, what fields does it hold (source, timestamp, wording shown, channel), and can you export it for a single contact on request? Second: when a contact unsubscribes in one campaign, is that suppression applied to every segment, every CRM sync and every future import, and how is a manual re-import of an old list blocked? Third: how are hard bounces and spam complaints captured, and do they automatically stop further sends to that address? Fourth: when two records match on email but differ on company or name, which system wins, and who approves the merge? Fifth: which Mautic release line will you run, when does its support end, and how will you move to the next line without a long freeze on sending?
A good answer is specific and checkable. The partner names the field, table or report where the evidence lives, describes who can change a suppression and whether that change is logged, and gives a written rule for duplicate handling rather than a general promise of data quality. For upgrades, a good answer ties the plan to the published support dates for the Mautic release in use, which you should confirm on the Mautic releases page before signing. Treat vague answers, or answers that depend on a vendor's hosted tooling you cannot inspect, as a reason to ask again in writing.
How to turn the checklist into a written scope
This sequence turns the requirements checklist into a written scope that names the owners, the open decisions and the tests that prove the platform works before go-live. Each step produces a record the next step depends on, so the agreement reflects the actual environment rather than assumptions.
Inventory contacts and send volume
Start by counting the contacts you will import, the active audiences you will mail, and the peak sends you expect in a normal month and during launches. Pull these figures from your current CRM, mailing tool and consent records, and note which lists contain people who have never opted in. Record the result as a single sizing sheet that the platform team, the marketing lead and the implementation partner all sign off. The step is done when every audience has a named source, a count and a sending frequency that someone can defend.
Assign owners for consent and deliverability
Name one accountable owner for consent capture and suppression, and one for sending domains, SPF, DKIM and DMARC records and bounce handling. The consent owner usually comes from legal, privacy or the business unit that collects data, while the deliverability owner sits with IT or the email operations team. Ask each owner to write down the rules they will approve, such as which forms require double opt-in and how unsubscribes must propagate to every list. The step is done when both owners have accepted their scope in writing.
Verify each requirement in a test environment
Stand up a non-production Mautic instance that matches the planned hosting, PHP and database versions, and test each checklist item against it. Confirm that cron jobs and the messenger consumer run on the schedule you intend, that a test send passes authentication checks for your sending domain, that a form submission records consent, and that a CRM sync creates the expected records. Keep a log of what passed, what failed and what you could not test. The step is done when each requirement has a pass, fail or not-yet-tested status with the evidence attached.
Record gaps as decisions
Every requirement that fails or cannot be verified becomes a decision record, not a silent assumption. Each record states the gap, the options (for example, a different sending service, a manual process for a short period, or deferring a channel), the cost and operational effect of each option, and the person who chooses. Keep the decision log next to the test log so later changes can be traced. The step is done when no open item lacks an owner and a choice.
Agree acceptance tests
Convert the verified requirements into acceptance tests that a third party could run. Examples include: an unsubscribe removes the contact from all active campaigns within the time your policy requires, a bounced address is suppressed, a segment update runs on schedule, and a campaign trigger fires once and only once. Agree the pass criteria, the test data and who signs off each result. The step is done when the test list is approved and linked to the decision log.
Put the agreed scope and timeline in writing
Before any production work begins, write down the scope, deliverables, acceptance tests, responsibilities, open decisions and the timeline agreed with the implementation partner. Ask the partner to confirm in writing which items are included, which are excluded and what the client must provide, such as DNS access, mailbox credentials and CRM API permissions. Confirm the schedule against the dates your organization can meet, not against an estimate from the vendor. The step is done when all named parties have signed the scope document.
How DeployOpen scopes, delivers and supports marketing automation
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For marketing automation, that means turning this checklist into a written scope for your Mautic environment, your sending setup and your CRM connection, then delivering and documenting each part before handover.
How we scope
- Written scope covering contact volume, send volume, consent sources and the segments and campaigns you need at launch
- Confirmation of DNS ownership for SPF, DKIM and DMARC records on your sending domains
- Agreed list of CRM objects, forms, landing pages and tracking requirements, with deliverables and timelines set before work starts
How we build
- Installation on a VPS or dedicated server in your cloud account or data center, not shared hosting
- Cron schedule for segment updates, campaign updates and triggers, plus broadcast and messenger workers sized to your send plan
- Configuration of consent capture, unsubscribe handling, SSO and CRM sync, tested against the agreed requirements
How we hand over
- Runbook covering cron jobs, queue workers, sending domains, backups and the consent and suppression configuration
- Documented test results for deliverability checks, form submissions, CRM sync and campaign triggers
- Knowledge transfer to your administrators so your team can operate the platform after handover
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, aligned to Mautic's release cadence
- Planned upgrades to a supported Mautic release line, with PHP and database version checks before each change
- Periodic review of cron health, queue backlog, bounce rates and access controls, with findings written up for your team
