Understand attention tags
- Needs answer: a client question waiting for a substantive answer.
- Unresolved issue: a problem that still needs action.
- Waiting on client: staff need information from the owner.
- Usage slowing: seven days without a real application attempt after onboarding.
- No recent applications: fourteen days without a real application attempt after onboarding.
- Lost Slack access and Payment trouble: recorded CRM risk reasons.
- Missed payment: verified Stripe facts show an unpaid renewal or an overdue plan. It appears for every owner, including onboarding, closed and snoozed owners, and only a Critical stage ranks higher. See Missed payments.
Verify an account relationship
Use Account relationship → Verify account link for legacy owners, including owners without an Onboarding setup record. Set the correct Sub-Account Location ID on the existing Retention opportunity in the CRM first, then refresh details. Verification checks the exact account’s agency and SaaS subscription, its exact Operations payment subscription, and the Operations contact against the existing CRM opportunity. Names and email similarity do not establish this relationship. Missing, conflicting or ambiguous evidence stays Needs review; a direct Stripe customer reference alone cannot identify an Operations contact. Reverify account link checks current evidence. Remove verified link reverses the saved relationship. If the CRM account field or contact changed, remove the original relationship first, correct the CRM mapping, then verify the intended account. Removal remains available if the account field was cleared. Check the result and message after either action; use Refresh details after a failed request before retrying. A link saved on another Retention opportunity must be removed from that original opportunity. Removed links stay marked Removed after a CRM correction and can be verified again against fresh evidence. These actions save only the internal account relationship. They do not change CRM fields or stages, billing, Slack, or Onboarding setup. A verified relationship enables private application activity where available and lets billing verification cover that exact Retention card (see Billing coverage). It does not establish a Slack channel mapping or Onboarding ownership. If the owner removed the app, verification can still prove the same SaaS account, Operations contact and payment subscription. The link is then saved as Verified for billing only: billing verification covers the card, while application activity, issues and Slack stay hidden. Another agency’s installation, a transferred installation, more than one installation, or a conflicting onboarding or Slack owner still blocks verification. If any of these appears later, billing coverage stops. Reinstalling the app does not upgrade the link, even when the matching Slack channel or onboarding record was kept; use Reverify account link after the reinstall.Review and resolve questions
Slack reviews run at 7am, noon, and 5pm Mountain time, weekdays only. Only changed conversations are reviewed. Conversations with unverified mappings wait for mapping recovery without blocking other eligible questions. Questions qualify after four elapsed hours, including nights and weekends; they appear at the next scheduled review. Acknowledgements such as “looking into it” do not count as substantive answers. Use Mark answered, Mark resolved, or Waiting on client immediately after handling an issue. Undo and Reopen reverse a decision. Resolving one conversation does not clear a tag while another qualifying issue remains. Old messages cannot undo a staff decision; a new client follow-up can reopen the conversation for review. A possible resolution found by the bot remains a suggestion until staff confirm it. Conversation context is bounded. The workspace shows the most recent conversations in each status and warns when more history exists. Tracking begins when the integration is enabled; use View thread for older Slack history. Free-workspace history limits also apply.Reply in Slack
Expand Slack conversation & reply to send a reply to that specific thread. It posts through FM Bot with your verified staff identity. Sending does not mark the issue resolved. If delivery is unconfirmed, use Check delivery / sync before another attempt. Do not paste the same reply into Slack until you have checked whether it already arrived. If staff verify that an update was not applied, the recovery control records that decision and allows a new attempt. A request that never reached the server can retry with its original identifier.Usage follow-ups
Choose a future date to snooze usage attention. The latest application date stays visible. Snoozing usage never hides a support or payment tag. Use Unsnooze usage to bring attention back early; a newer application attempt supersedes the snooze.CRM synchronization
CRM stages are read on refresh. The roster refreshes every minute while visible; Refresh details checks the selected owner immediately. Stage edits require confirmation and are checked against the current CRM record. Moving to Churned closes the opportunity as lost; moving back to a live stage reopens it. Changing stages never clears unrelated support issues. Managed retention tags sync in the background. Other CRM tags are preserved. A sync error leaves local staff decisions saved and offers Retry tag sync. Usage, retrieval and risk tags sync once the account mapping is verified; a Slack channel is not required. Needs answer, Unresolved issue and Waiting on client change only when a verified Slack channel is mapped. Each group of tags changes only when its source was read: if Slack, application activity or the Churn Risk Reason field is unavailable or unreadable, the existing CRM tags in that group stay as they are. Retrieval trouble is removed only when too few applications have an unknown outcome to reach two. If an owner’s CRM stage or status is not one the app recognizes, only Slack issue tags change. If the Churn Risk Reason field or a live owner’s value cannot be read, the owner shows Churn Risk Reason unreadable in CRM · existing risk tags kept; correct the field or value in the CRM to resume risk tag updates. If the account mapping is unverified or a contact has duplicate Retention cards, all existing CRM tags are preserved for staff review.Availability
Admin access is required. Account, contact, agency and Slack channel mappings must agree before private activity is shown. Replies require a verified private support channel with FM Bot present. Unverified, archived, disconnected or unsupported channels retain their Slack link when available and explain why direct replies are unavailable. The new review, direct replies and CRM writes each have a deployment switch. Until enabled, the view explains which integration is unavailable; setup does not itself activate production writes.Client progress and context
An Applicant represents a real report/application attempt. The 7- and 30-day counts deduplicate by Contact; a retry renews activity but does not inflate the Applicant count. Legacy records without a Contact use their request identity and show a coverage warning. Counts describe stored attempts: requests that failed before storage are unavailable. A returned credit file is not a guaranteed score or funding outcome. Processing submission/completion are separate milestones; unavailable funding dates are shown as unknown. Use Edit client context to record the owner’s goal, known blocker, next milestone and preferred contact channel. Existing onboarding blockers appear as handoff context and should be confirmed before being treated as current. Context and commitments recorded before account setup stay with the same CRM owner when their account is independently verified. Work already tied to another account is not transferred by changing the CRM account field.Commitments and recent contact
Use Add a commitment to record the next action, responsible teammate and a future follow-up date. Complete action, Wait on client, Cancel action, Resume action, and Reopen action preserve the history. Follow-ups can be rescheduled and have an optional outcome. The Follow-ups view includes owners with open commitments; overdue work is visible in the attention queue for live owners. A commitment does not assign the entire account or resolve support tags. Future open commitments defer generic automated retention check-ins until their due date or closure. Necessary onboarding handoffs remain eligible. Recent client contact combines bounded Slack context with verified CRM messages and call metadata. Calls handled elsewhere are unknown unless recorded in a connected source.Missed payments
Subscription & service is the first section in the owner workspace. When a renewal fails, it shows a Missed payment alert with the unpaid amount, how many open invoices it covers, the payment attempt count, when the first unpaid invoice was issued, and the next automatic retry. For multiple open invoices, the attempt label shows the highest count on one invoice. A missed payment is not a cancellation: it never moves the card to Churned or pauses outreach. Contact the owner and record a commitment for the follow-up. Stripe retries a failed card automatically for a limited period. Under the current Stripe settings, when the retries run out Stripe cancels the subscription and the invoice stays unpaid, so the alert remains on a canceled owner until the balance is settled. An active subscription can also carry an older unpaid invoice; it still shows Missed payment. The section keeps these dates separate:- Next regular bill: the end of the current billing period, when Stripe next bills the plan. Only a renewal still ahead of the check counts. While collection is paused, it counts only if collection resumes before the renewal; otherwise it shows as unknown and needs review, never as no further bill.
- Next payment retry: when Stripe will next try the unpaid invoice. This is usually earlier than the next regular bill.
- Paid through (invoices): the end of the latest period covered by a paid subscription invoice.
- Confirmed paid-through arrangement: a manual service arrangement that staff record. It is separate from invoice history.
Cancellation and reactivation
The Subscription & service section separates active service, scheduled cancellation, confirmed service end, incomplete signup and billing that needs review. Billing review surfaces exceptions; Historical owners retains closed owners. Trial history is kept distinct from verified paid subscription history. Once billing verification and CRM writes are enabled, a confirmed terminal cancellation moves the existing Retention opportunity to Churned / lost and pauses automated onboarding/retention outreach. A scheduled cancellation stays pending while service is active. An expired signup, payment failure, incomplete lookup, unknown subscription or conflicting mapping cannot establish churn. A verified replacement subscription or an explicitly approved paid-through arrangement can keep service active. Confirmed paid-through arrangement records its end date and reason; Clear arrangement reverses it. This does not modify Stripe or charge the owner. An old paid invoice alone does not extend service after an immediate cancellation. Reactivation restores the previous CRM stage only when the card still matches the automation’s own Churned update. A later staff edit requires review, and outreach remains paused until restoration is confirmed. Each new automatic closure records its own preceding stage, so a later reactivation does not restore an older cycle. Staff can still handle individual support conversations during closure. Existing engine engagement-stage rules are unchanged; a reply alone does not remove the separate application-activity tags. Legacy accounts without a verified onboarding account link or a verified account relationship need mapping repair before automatic billing decisions are available. Native cancellation state remains visible when a CRM billing field is unavailable; see CRM billing fields.CRM billing fields
When CRM writes are enabled, each billing check updates the Retention card’s Billing status, Trial end / Next billing date and Paid-through date together from the Stripe facts above. A missed payment changes only these fields; the stage and open status stay as staff set them.
A past-due owner is never shown as Active — paying. The next billing date is blank
once no further bill is scheduled. Dates are written as the calendar day in the
timezone each date field declares, so a bill at 11 PM Mountain time on November 9 is
written as November 9.
All three fields stay as staff set them, with the reason shown, when:
- the card shows Paid through — annual/prepaid, Billing deferred — extension/guarantee or Complimentary — confirmed;
- a confirmed paid-through arrangement is recorded;
- another subscription may replace the plan, open invoices use more than one currency, or the next bill is unclear, including a pause with no resume before the next renewal;
- staff change any of the three fields, or set an approved exception, while the check is updating them; the card keeps the change and the check asks for a refresh;
- a field is missing, has the wrong type, lacks a required option or declares an unsupported timezone.
Verify billing and handle exceptions
Use Subscription & service → Verify billing now to refresh the selected owner’s current provider evidence. Check Verified, CRM stage sync, the sync message and Subscription history after the request completes. Billing review contains exceptions; Historical owners includes closed cards. An enabled integration or a successfully delivered webhook does not establish that a particular owner has been verified. Billing reconciliation also runs every fifteen minutes for existing verified onboarding account links and verified account relationships. When the Stripe webhook is configured, a subscription or invoice event starts a check sooner. Legacy owners without either are not automatically repaired. Missing credentials or an unavailable mapping can leave billing unverified. A failed provider lookup, including the confirmation read before a CRM update, keeps the cancellation safeguards that existed before the check and starts no new ones. If billing changes between those reads, only the latest evidence is saved and the CRM card is left for the next check; a confirmation read for a different payment customer counts as a failed lookup. An onboarding account link that changes or needs review during a check, or that names a different Stripe customer than the saved billing record, holds billing for review without updating the CRM card. A manual refresh may show Billing state saved. CRM stage sync is disabled. when native verification is enabled before CRM writes. For an unconfirmed CRM update, inspect the current CRM card and use Verify billing now again. The integration checks current state before another update. If the card was edited after automated closure, send it to the responsible teammate for mapping or recovery review. Do not reopen it solely because a payment or reply arrived. If maintainers disable the integration, saved cancellations and pending recovery remain in effect. Disabling billing does not resume outreach or reopen CRM cards. Verified service and confirmed CRM recovery are required to resume. Staff support conversations remain available according to their separate reply permissions.Billing coverage
Subscription & service → Coverage shows why billing verification covers an owner:- Onboarding account link — the owner’s verified onboarding account link.
- Verified account link — a verified account relationship from Account relationship, used when no complete onboarding account link exists.
- Verified billing link · account data stays hidden — a relationship verified for billing only because the app is not installed.
- the CRM subscription, contact, payment subscription or Retention card no longer matches the saved relationship, including a change while the check is running;
- the CRM SaaS subscription is billed directly in Stripe, or the payment record is in test mode;
- the relationship conflicts with onboarding, Slack or other account records, or the owner previously used a different coverage source (except the agreeing onboarding account link described below);
- the onboarding account link and the relationship name different CRM subscriptions;
- the relationship was removed or reverified while the check was running.