Library·SOP·Operations
Diagnose delayed, expired, failed or uncertain email sends; assign an investigation and record recipient confirmation separately from provider status.
Last reviewed: · Editorial review
Clarity, structure and references reviewed in this version. This is not a test in a live account.
Find the exact opportunity email, distinguish the recorded send status from a human receipt report, and leave an accountable investigation with evidence and a deadline. Use app.6am.ag, select the correct company, and open Email deliveries. Permission to manage contacts is required.
This procedure covers the explicit opportunity email flow from SOP 110. The current app does not implement GoHighLevel workflow enrollment, inbox synchronization, bulk newsletters or automatic email sequences. Never interpret a missing record as proof that one of those automations failed.
Record the company, opportunity, pipeline, original recipient, subject, expected send time and time zone. Keep the expected send time separate from the deadline for the team's personal response.
In Sales opportunities → E-mail → Email delivery history, check whether a send was requested. Follow the link to Email deliveries, filtered to that opportunity. You can also open the page from navigation and filter by pipeline, opportunity, owner, investigation status or recorded send status.
If there is no record, check filters and the exact opportunity. Saving or approving a draft does not send it: SOP 110 requires a separate preview, confirmation and send action. Record the investigation and next response through the opportunity's follow-up task when there is no delivery record; do not create a fictional delivery or send a copy just to test a customer's address.
Open Investigate / record receipt. Read the original recipient and subject, Current diagnosis and Suggested next step.
| Diagnosis | Meaning and next step |
|---|---|
| Queued, under 2 minutes | Initial processing window. Wait and set a review deadline. |
| Queued for at least 2 minutes | A review threshold, not proof of provider rejection. Ask the technical owner to check the dedicated sales-email worker and outbox recovery. |
| Request expired, 15 minutes | An unprocessed request cannot be sent after this window. The worker cancels it when processing resumes. Do not enqueue a duplicate. |
| Send in progress | Wait for the current attempt. |
| Uncertain result | A timeout or interrupted worker may hide a successful provider acceptance. A sending record older than two minutes is displayed as uncertain. Do not retry. |
| Accepted | Provider accepted the message. Acceptance alone does not confirm inbox placement; check the separate manual receipt report. |
| Delayed | Provider reports a delivery delay; review the provider record and set a deadline. |
| Delivered | Provider reports delivery, not inbox placement or reading. |
| Failed / bounced | Read the result code and check the original address and sender configuration. Escalate credential/domain issues to the technical owner. |
| Complaint | Respect the complaint and stop further outreach; do not override preferences. |
| Cancelled | Context, approval, recipient, task, sender or permissions changed before sending. Older generic cancellation codes may also include expiration; preserve uncertainty without supporting evidence. |
The Delivery needs attention filter shows problematic send states even if their investigation was resolved. Combine it with investigation status to review open work. Overdue investigations uses open cases whose deadline is before today in UTC.
For a record with a provider ID, Check delivery with provider performs a read-only status lookup. It does not send. If the key is restricted or the service is unavailable, the screen shows the limitation and preserves the previous provider status. Do not treat this as proof that sending failed and do not broaden credentials as an ad hoc workaround.
Use the request's exact provider ID in Resend with an authorized account, or ask the technical owner. Record the findings in the investigation. Do not paste API keys, passwords or unrelated personal data into evidence.
Choose Open, an active company member with contact-management permission, and a deadline. Enter:
The deadline is a calendar date evaluated in UTC. It belongs to the investigation and does not replace the opportunity's commercial follow-up task. This module does not send reminders. Review the list operationally.
Save and verify owner, deadline and investigation status in the table. A stale-edit warning means another review was saved; close and reopen before reconciling changes. Do not overwrite it blindly.
Set Manual receipt report to not confirmed, inbox, spam or not received. For a report, enter who confirmed it, when, the exact message and the channel in Receipt evidence. A recipient's statement supports the manual report; provider acceptance alone does not. A record with no attempted send cannot be marked as received.
Example: the authorized QA recipient says “Received in the inbox” in the existing chat. Record inbox placement and that source; keep the provider's accepted status intact. A report can be corrected with new evidence; the previous review remains in Investigation history.
Resolve only after recording a reason and a clear disposition for any remaining work. A valid wait, confirmed receipt or respected customer preference can need no technical change. If a correction needs testing, use synthetic data and a specifically authorized team inbox, not the affected customer by default.
Saving a review does not send or retry email, change provider status, complete tasks, move a pipeline stage or mark a deal won. Resolving an uncertain result does not remove its duplicate-send block. Any future new message requires its own reviewed context and the SOP 110 send flow; do not change identifiers, statuses or evidence to bypass a block.
Review Investigation history for actor, UTC timestamp, revision, owner, deadline, evidence, disposition and manual receipt. Confirm that the opportunity and commercial task still reflect the real next action.
