Importing and Verifying Recipients in GQ CRM

The single most effective thing you can do for deliverability is not sending to bad addresses. GQ CRM makes this concrete: you import recipients, run verification, review the invalid reasons, and only then send. This guide covers the full flow — import, verification states, dedupe, and the playbook for keeping your list healthy.

1. Add recipients to a task

Open Email Tasks → New Task and add recipients in one of two ways:

• Paste a list — one email per line (optionally with name, email or email, name columns)
• Upload a CSV — with an email column, plus any custom fields you want to personalize with

For bigger or messier lists, import on the Contacts page instead (Contacts → Import), which takes both pasted CSV and uploaded files:

• Formats — .csv, .tsv, .txt (comma- or tab-separated) and .xlsx (Excel). A legacy .xls must be re-saved as .xlsx or .csv first.
• Limits — up to 5 MB and 5,000 rows per file; the first row is the header and an email column is required.
• Columns — email, name, company, title, phone, website, address, source, stage, tags.
• Duplicates — Skip (keep existing) leaves the name, stage, tags and notes you edited by hand untouched. Update existing overwrites name, company, title, phone, website, address, source and stage with the file's non-empty values, replaces tags when the row provides them, and never touches notes. Either way the summary reports created / updated / skipped / failed.

Recipients you add are automatically collected into your Contacts (Contacts page), where you can tag them by stage (LEAD → CONTACTED → FOLLOWING → WON/LOST).

2. How verification works (manual by design)

GQ CRM's verification is manual by design: the system never silently verifies, skips, or removes recipients. Nothing is checked at import time, and validation only happens when you explicitly trigger it. The state of each recipient is shown in the task's Validity column:

Select recipients and click Verify (or Verify all) to run the checks.

3. What the checks flag

Verification runs synchronous checks and reports why an address is invalid:

Note: example.com and friends are always invalid — never treat them as test-valid. If you're testing, use a real address you control.

4. Dedupe and preflight

While composing a task, GQ CRM runs a preflight check that warns about recipients already sent the same project + template. The dedupe mode on the task controls what happens at save time:

• Warn (default) — only warn, keep every recipient
• Skip — remove addresses already sent for this project + template (if all would be removed, saving fails with a 409)
• Allow — no dedupe filtering

Nothing is ever removed silently: hand-added recipients are never dropped without your explicit choice.

5. The send gate

When you click Start, the confirmation dialog shows the verification state and lets you choose:

• Skip invalid (recommended) — send only verified valid recipients; flagged addresses are marked SKIPPED
• Send all — send everything, including flagged addresses (bounces hurt your domain; not recommended)

GQ CRM never blocks a send on its own — the decision belongs to you.

6. The operator playbook

1. Verify before sending — run "Verify all" on the task page, then review the invalid reasons.
2. Fix typos — an address marked invalid for format can be corrected and re-verified.
3. Delete offenders explicitly — remove disposable/reserved-domain addresses from the task (the UI offers "remove all invalid" with a confirmation dialog).
4. Export for offline remediation — the export endpoint (/api/email-tasks/[id]/recipients/export?status=INVALID&format=csv) gives you Email,Status,IsValid,InvalidReason,SentAt,Error for cleaning lists outside GQ CRM.
5. React to bounces — after sending, drop hard-bounced addresses from future campaigns; keep soft-bounced ones for retry.

Troubleshooting

• "Pending" recipients that never change — verification is manual; select them and click Verify.
• Duplicate warnings you didn't expect — the preflight only counts SENT recipients on non-cancelled tasks of the same project + template; queued history doesn't count.
• A valid-looking address is flagged — check the reason: disposable-domain and reserved-domain checks are intentional (no, example.com is not valid).
• Saving fails with a 409 — skip dedupe mode would remove every recipient; switch to warn or remove the duplicates manually.

A healthy list is the foundation of deliverability. Verify before you send, prune what's invalid, and let per-recipient data tell you who's actually engaging — then send follow-ups to the people who deserve them.