Migrate from Service Autopilot to Mailchimp

Service Autopilot clients map directly to Mailchimp contacts. We map standard fields (name, email, phone, address, company) to Mailchimp merge fields. All Service Autopilot custom fields on the client record map to Mailchimp custom contact fields. This direct mapping ensures that all client identifiers, contact details, and custom attributes are available in Mailchimp for segmentation and campaign targeting.

Service Autopilot leads migrate as Mailchimp contacts with their original lead status preserved in a custom field. Mailchimp does not have a native lead concept — leads land in the same audience as clients but retain a custom field flag distinguishing them.

Service Autopilot notes on a client record have no native Mailchimp field. We create a custom text field (sa_notes) on the Mailchimp contact and store the full note content, preserving the original author and timestamp as available from the export.

Service Autopilot stores job history as a related list, not a flat client field. We extract the most recent job records and store a summary (job count, last service date, last service type) as a custom field on the Mailchimp contact.

Invoice amounts do not map to any Mailchimp standard field. We extract the most recent paid invoice amount and store it as a numeric custom field (sa_last_invoice_amount) on the contact for segmentation and reference. This allows you to filter contacts by revenue tier, target high-value clients with exclusive offers, and track payment patterns over time.

Service Autopilot payment status (current, overdue, etc.) is not a Mailchimp concept. We store the status as a custom pick-list field (sa_payment_status) so your team can filter contacts by payment standing in Mailchimp segments. This enables targeted follow-up campaigns, overdue reminders, and payment collection workflows based on the stored status.

The conversion date when a lead became a client is a Service Autopilot concept. We preserve this as a date custom field (sa_client_since) so you can segment by client tenure in Mailchimp without losing the original timeline. This date also helps in anniversary-based marketing, such as loyalty rewards or renewal notices.

Service Autopilot stores which technician is assigned to a client. Mailchimp has no native technician assignment field. We store the assigned employee name as a custom field (sa_assigned_technician) so the reference survives the migration. This allows you to route service-related campaigns to the correct technician or notify them of client updates.

The last service date is a Service Autopilot scheduling field. We carry it as a custom date field (sa_last_service_date) on the Mailchimp contact so you can build re-engagement automations for clients who have not had a service recently. This helps schedule follow-up reminders and maintenance tips based on elapsed time since the last visit.

Service Autopilot owner (sales rep) IDs do not have a Mailchimp equivalent. We resolve the owner name from the ID and store it in a custom field (sa_owner_name) for reference on the contact record. This allows your sales team to attribute leads and clients to specific reps, facilitating performance tracking and personalized outreach.

Service Autopilot records which user created a client. We resolve the creator's name from the user ID and store it in sa_created_by as a custom field. This preserves audit history without requiring a Mailchimp user management concept. It also supports compliance reviews by linking each contact to its originating user for accountability.

The Service Autopilot internal user ID is stored as a custom field (sa_user_id) on the Mailchimp contact for traceability, delta-run de-duplication, and cross-referencing back to the source system. This identifier also facilitates data reconciliation during subsequent syncs, ensuring that any updates in Service Autopilot are accurately reflected in Mailchimp without duplicate entries.

Service Autopilot tags map directly to Mailchimp tags. Both platforms use a flat tag model with no hierarchy. All tags on a client or lead are applied to the corresponding Mailchimp contact, allowing you to recreate segments and automations from the same tag structure.

Service Autopilot property data (service address, GPS coordinates) is nested under the client. We extract the primary property and map address components to the Mailchimp native address merge field, while GPS lat/long values are stored in custom fields (sa_latitude, sa_longitude).

Service Autopilot property type (residential, commercial, etc.) is a custom field with no Mailchimp standard equivalent. We map it to a custom pick-list field (sa_property_type) so you can segment your Mailchimp audience by property type. This enables targeted campaigns that address specific property needs, such as seasonal maintenance for residential clients or bulk services for commercial accounts.

Equipment data stored on a Service Autopilot property record (lawn mower model, HVAC unit, pool type) does not map to any Mailchimp standard field. We create a custom text field (sa_equipment) on the contact to preserve this data. This allows you to send equipment-specific tips, warranty info, or service reminders based on the equipment installed at each property.

Property-level notes from Service Autopilot are stored in a custom text field (sa_property_notes) on the Mailchimp contact. This keeps property-specific context attached to the client record for reference in future service communications. You can use these notes to personalize email content, schedule follow-ups based on property issues, or share relevant details with technicians before site visits.

Service Autopilot lead status values (New, Contacted, Qualified, etc.) are preserved in a custom pick-list field (sa_lead_status) on the Mailchimp contact. Mailchimp has no native lead-status concept, so this field enables lead-stage-based segmentation. You can design automated nurture paths that progress leads through stages, tailor content to each status, and prioritize follow-ups for high-intent prospects.