> ## Documentation Index > Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt > Use this file to discover all available pages before exploring further. # Retention workspace > Review owner health, resolve support issues, and keep retention stages in sync with your CRM. Open **Admin → Retention** to see the complete Retention pipeline, including owners who are still onboarding and closed opportunities. **Needs attention** focuses on live owners; use **All owners** or **Onboarding** for the full roster. Setup work stays in the Onboarding workspace. ## 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](#missed-payments). Application activity includes Credit Not Found and stored failed retrieval attempts, and excludes samples. The usage clock starts at the later of the **Onboarding Completed Date** and the latest real application attempt, so an owner without a recorded completion date is still measured from their latest application. When neither date is recorded, the owner shows **Usage baseline unknown** in Needs attention instead of a usage tag; record the completion date in the CRM to start the clock. If the completion date cannot be read from the CRM, the row shows **Completion date unreadable · usage unknown** and existing usage tags are kept. Onboarding owners do not receive usage tags. An unavailable mapping is shown as unknown, never as proof that an owner has stopped using the app. **Last completed report request** reflects the request's status only. It does not confirm that a credit file was returned. Owners still using Zoho can link their legacy account separately. See [Retention across Zoho and CRM](/staff/retention-platforms) for source labels, report freshness, and correcting a Zoho link. ## 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](#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. Times are shown in Mountain time. **Payment facts read** shows when Stripe was last read successfully. If a later check fails, the last facts stay visible and are marked as not current. A paid invoice clears the alert at the next check, and **Subscription history** records both changes. Use **Billing review** to list every owner with a missed payment or unverified billing, including CRM billing fields that need review, are unconfirmed or disagree with Stripe. An owner whose payment facts were never read from Stripe shows **Billing unverified** instead of looking healthy. Changes to CRM exceptions or field definitions appear in **Billing review** as soon as the roster is refreshed, even when the previous billing check confirmed synchronization. For an overdue or paused plan, the section says the payment is overdue or paused and that service is not canceled. **CRM stage sync** shows the stage is unchanged; the CRM billing fields report their own sync separately. ## 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). ## 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. | Stripe facts | Billing status | | - | - | | Unpaid renewal or overdue plan, active or with a scheduled cancellation | Past due | | Collection paused, resuming before the next renewal | Paused | | Trial | Trial — new customer | | Paid and current | Active — paying | | Confirmed cancellation | Canceled | 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. The **CRM billing fields** table compares each value on the card with what Stripe supports and marks any mismatch. With CRM writes off, billing facts are saved in the workspace only and the mismatch stays visible. These updates never change prices, subscriptions or charges. ## 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. An onboarding account link takes precedence when both exist, except that a verified billing-only relationship covers an owner whose app was removed. Any retained onboarding link must agree on contact, subscription and payment customer; its original onboarding card and cancellation safeguards stay recorded. After reinstall and explicit reverification, the agreeing onboarding link takes over again. The verified account relationship is checked in either case. Billing coverage from a verified account relationship applies only to its exact Retention card. It does not create Slack, Onboarding setup or other Location access. Every billing check that uses a verified account relationship, as coverage or alongside an onboarding account link, confirms the current CRM SaaS subscription, the Operations contact and its payment subscription against the saved relationship, using live provider records. Any of these keeps billing **Needs review** without changing the CRM card or pausing outreach: * 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. If an owner covered by a verified account relationship later gets a complete onboarding account link, the link takes over at the next billing check only when it names the same contact, CRM subscription and payment customer that billing already saved, and the relationship is still verified and names the same Retention card. The handover compares only these saved records. Saved cancellations, paused outreach and pending CRM recovery carry over, and that check confirms both sources against live records before saving any billing result; if that fails, billing goes to **Needs review** under the onboarding account link. If they disagree, billing stays **Needs review** under the relationship. **Remove verified link** ends this coverage at the next billing check; **Verify billing now** then refuses the owner. Once the link is removed, **Subscription & service** no longer shows the saved billing state and the owner leaves **Billing review**. Saved cancellations and paused outreach stay in effect until verified service and CRM recovery are confirmed. After correcting the CRM mapping, reverify the account link and use **Verify billing now**. Reverifying does not clear a disagreement between the onboarding account link and the relationship about the CRM subscription: follow **Changed name or subscription identity** in [Automatic onboarding account links](/staff/onboarding-account-linking), then use **Verify billing now**. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.