Organize and segment contacts in 6am

Outcome and scope

Organize contacts in the correct 6am company and save a segment whose inclusion rule another operator can explain and reproduce. Start with the business decision, then choose existing contact fields, manual tags, a dynamic list, or tags applied by a native lead form.

Responsible: an operator allowed to manage contacts in the selected company. Confirm the company in the sidebar before changing records. Use verified contact information; do not invent answers or newsletter permission.

Available: six contact fields (First name, Last name, Email, Phone, Company and Notes), tags, saved AND/OR rules and form-submission tagging. Custom contact fields, city/service dropdowns and generic event workflows are not part of this procedure. A segment does not send messages, grant consent or create pipeline opportunities automatically.

1. Write the inclusion rule before editing

Record the segment's purpose, its owner, the information that makes a contact qualify, and what should remove the contact. Choose a clear name such as SEO interest — company Example. Use the same vocabulary across the team; reuse an existing tag when its meaning matches.

Example: Company equals Example AND has tag interest:seo. A contact at Example without the tag is a nonmatch; a tagged contact at another company is also a nonmatch. These are sample values, not instructions to alter real records.

Decide whether missing values should qualify. Negative text rules include empty fields: Company is not equal to Example also matches a missing company. Add Company is not empty in the same group when missing values must be excluded.

2. Choose the right method

A manual tag does not disappear when a company's name changes. A dynamic list can stop including that contact while the tag remains. A form tag records a submission, not continuing eligibility for every segment.

If the requirement depends on a missing structured field, record that product requirement and agree a supported rule with the owner. Do not claim the field exists or repurpose a name/email field. Notes are free text, not a validated dropdown or a substitute for structured consent.

3. Prepare the contact data and tags

1. Open Contacts in the selected company. Find the intended record, choose Edit, update only confirmed values and save. Reopen it to verify. Use SOP 083 for imports and SOP 081 for duplicates rather than silently creating another record.
2. Open Contact tags and reuse or create the agreed label. Return to Contacts and use Add tags or Remove tags on the exact record. Adding preserves other tags; removing affects only the selected tags. Follow SOP 085.
3. For a batch, filter first, review the visible records and select only the intended contacts. Selection is limited to the current page; it does not select an entire multi-page segment. The service accepts at most 500 contacts and 50 tags per operation. Check the selected count before confirming and recheck the resulting tags afterward.
4. Renaming a tag preserves its associations. Deleting a tag removes its associations without deleting contacts, but breaks lists that reference it. Review dependent lists and form settings before deleting shared labels.

4. Build and inspect the dynamic list

1. Open Smart lists → Create smart list, enter a unique, meaningful name and add an alternative group if none is shown.
2. In Conditions in this group (AND), choose the contact field, operator and value. Add another condition for every requirement that must also be true. For the example, put Company equals Example and Tag has interest:seo in the same group.
3. Use Add alternative (OR) only for a separate complete route to qualification. Any matching group is enough. Repeat shared restrictions in every alternative that needs them; an OR group is not an additional mandatory condition. Maximum: five groups with five conditions each.
4. Text supports equals, does not equal, contains, does not contain, empty and not empty. Comparisons ignore letter case; % and _ are literal characters, not wildcard commands. Tags support has/does not have. Select an existing tag belonging to this company.
5. Choose Preview count. The notification shows matches now; it does not save the list or freeze its members. Investigate zero or unexpectedly broad results before saving.
6. Choose Save list, then View contacts on that list's row. Confirm the active dynamic-list filter, displayed list name, current total and actual people. A correct count alone is not enough. Follow SOP 086 for the detailed list workflow.

Archived contacts are excluded. List members can change as fields or tags change; reopen or refresh to recalculate. Removing the filter shows the broader contact table. A missing referenced tag invalidates the entire list, including OR alternatives and negative tag rules: the list shows a review warning and no contacts until its rules are repaired. Do not treat that warning as a healthy empty segment.

5. Use form tags when the submission is the qualifying event

Follow SOP 074 and SOP 087. Configure up to ten existing company tags on the intended native form, review and publish it. Editing a published form requires publishing again.

Valid submissions add the configured tags to a new contact or the existing contact matched by email, preserving earlier tags. Existing contact fields are not overwritten. Identity conflicts, archived contacts or retired identifiers require review instead of automatic tagging. Inspect Form submissions for the outcome. The visitor's message stays with the submission; it does not become contact Notes.

A changed form configuration does not tag old submissions retroactively. Review and tag earlier contacts separately when the recorded evidence supports it. Use a dynamic list with the form tag plus other current conditions when a submission alone is not enough to qualify.

6. Verify inclusion, exclusion and change

For each distinct qualification path, record one expected match and one expected nonmatch, the relevant values/tags and the expected result. Use synthetic records in an approved QA context for deliberate changes.

• Confirm a matching contact appears through View contacts.
• Confirm a contact that fails a mandatory condition does not appear.
• For an OR list, confirm each alternative works and does not bypass restrictions meant to apply to everyone.
• In QA, change one relevant field or add/remove a test tag, refresh and confirm membership changes as expected. Restore the test state afterward. Do not alter real customer data merely to exercise the rule.
• Review the whole resulting segment, not only the examples, before a bulk action. Recheck after edits or when the segment is reused.

7. Hand off the segment for its actual purpose

Save the list name, rule, owner, review date and evidence of the inclusion/exclusion checks in the team's work record. Investigate ambiguous values rather than silently broadening the rules.

For commercial routing, follow SOP 105: explicitly preview and confirm the intended pipeline and stage. Changing list membership alone does not synchronize opportunities.

For newsletters, follow SOP 109. List membership or a tag is not permission to email. Eligibility, suppression, reviewed recipients and authorization are checked separately in the newsletter workflow.

Completion criteria

• Correct company and operator permissions confirmed.
• Business rule, owner and handling of missing values recorded.
• Supported fields/tags used consistently; no invented custom-field capability.
• Saved list opens with the correct filter and identifiable members.
• Positive, negative and relevant alternative paths checked; QA changes restored.
• No unresolved missing-tag warning or unexplained result count.
• Downstream pipeline or newsletter actions remain explicit and separately reviewed.