Keep the account's working story available
Iris is the customer success assistant project for customer success managers and account teams. It brings the customer's objective, the team's promises, adoption evidence, and unresolved difficulties into account preparation. Before a conversation, the account owner needs to understand what has changed and what still needs agreement. Afterwards, the next person working with the customer needs an accurate record of that agreement.
The relevant context often sits across a CRM, support conversations, account-level product analytics, and meeting notes. These sources describe different parts of the relationship. A support ticket may explain a technical obstacle, while a meeting note explains why the customer needs that obstacle removed. Usage data can show whether activity changed, but it may not explain which business objective that activity was supposed to support.
In a manual account review, a manager reads those sources before each review, reconstructs earlier commitments, and checks with colleagues about missing details. A handover can make the reconstruction harder because the new owner did not attend the earlier conversations. Iris addresses that preparation work by keeping the account's working story tied to available evidence.
Account health needs explanation before it can support a decision. High support volume can reflect engagement or frustration. Low usage can reflect seasonal activity, incomplete implementation, or a lost champion. Iris's role is to bring those signals into context without turning one of them into a diagnosis. The detailed model below follows one illustrative stalled-onboarding review through preparation, agreement, and later account work.
Start onboarding with the customer's objective
An onboarding plan should connect the customer's agreed objective to milestones, responsibilities, prerequisites, and signs of adoption. Completion needs a meaning that the account owner and customer can recognize. Finishing a setup task may enable useful work without establishing that the customer has started doing that work. Iris's proposed planning workflow would preserve that distinction when translating the objective into a milestone draft.
Consider an illustrative request to prepare tomorrow's account review: explain why onboarding has stalled, what the team has already tried, and what needs agreement with the customer. Suppose the account record describes a customer seeking a repeatable workflow that depends on a particular integration. The walkthrough follows this hypothetical dependency through the account review and subsequent preparation.
Iris would compare the onboarding plan with the available product events and support history. The first question would be whether the integration is documented as a prerequisite for the next milestone. If it is, an unfinished connection could explain why that milestone remains open. If the record merely mentions an integration among several requests, the assistant would need to preserve the uncertainty instead of treating it as the cause of the stall.
A milestone draft would then identify the last agreed owner, the required input, and the evidence expected when the step is complete. A named responsibility from an earlier meeting would remain part of the history, but its current status might need reconfirmation. If no owner had been agreed, Iris would put that question on the agenda rather than assign a person to make the plan look finished.
The manager would also need to know whether any independent onboarding work could continue. A documented dependency may block one milestone without blocking the entire plan. In this example, Iris could propose checking that distinction against the existing plan. The account owner could then discuss realistic progress with the customer instead of allowing a single unresolved item to obscure every other commitment.
Read usage and support as evidence with context
The account brief would explain what each signal establishes. In the continuing example, a low level of product activity would show limited recorded use within the available period. It would not, by itself, prove that the customer had abandoned onboarding. The integration history and earlier meeting commitments would determine whether there is a supported explanation or a question for tomorrow's review.
Iris would need to compare activity with the milestone being assessed. Events related to initial setup could support a claim that setup was attempted, while leaving the intended working process unverified. If the recorded events do not describe successful use of that process, the brief should say what remains unknown. Otherwise, an account manager could mistake technical activity for the customer reaching the outcome they bought the product to achieve.
Support history would add the sequence of attempts. Suppose the same integration question appears in a ticket, a meeting note, and a later internal summary. Those records could describe one unresolved problem rather than several independent failures. In this walkthrough, Iris would organize them as a connected history so the manager can see what was tried, what response was recorded, and what still lacks an answer.
The result of an earlier attempt matters as much as its existence. Advice sent to the customer is evidence that advice was provided. It does not establish that the customer followed it or that the integration then worked. A review brief would distinguish a suggested step, an attempted step, and a confirmed outcome wherever the records support those states. That helps prevent the next meeting from reopening an already exhausted troubleshooting path.
Stakeholder changes also belong in the explanation. If the documented contact responsible for the missing input has changed, the manager needs to reconfirm ownership. If the history contains no recent confirmation, Iris would flag the statement for review. It should not infer that a champion has left solely because usage declined or a message went unanswered.
The output would be an account health explanation with sources behind material claims and a visible missing-context list. That gives the owner a basis for choosing between technical follow-up, clarification of responsibilities, or a conversation about the customer's current objective. Each choice addresses a different possible cause of the same apparent lack of progress.
Make tomorrow's meeting resolve the dependency
The proposed meeting agenda would lead with the agreement needed to move the onboarding milestone forward. Where the integration dependency is documented, the brief would identify the missing input and the last agreed responsibility. The account manager could use the conversation to confirm whether those details still apply and what each side can commit to next.
The supporting account story would include the customer's objective, progress so far, previous attempts, unresolved support themes, and the latest commitments. It would also mark statements that need reconfirmation before the manager repeats them. A concise agenda depends on that preparation: the manager needs enough history to ask a focused question without reading every ticket aloud to the customer.
If the records did not establish why the integration remained unfinished, the agenda would ask about the obstacle. It would not tell the customer that lack of engagement caused the delay. A question about the missing input can reveal whether the owner changed, the prerequisite was misunderstood, or the agreed objective itself needs revisiting. Those possibilities belong to the discussion until the evidence narrows them.
Iris would prepare a revised milestone draft alongside the agenda. In the illustrative review, the draft could show the dependent milestone as awaiting agreement while preserving any steps already supported as complete. A proposed date would remain a proposal until the customer and authorized owner agree to it. That distinction matters when a draft later becomes the basis for an internal status update.
The preparation could also include a follow-up email draft, but the meeting's actual decisions would determine its final contents. Before the call, the draft can organize questions and possible next steps. After the call, it needs to record what was agreed, what remains open, and which prior statements changed. The account manager would review the message before it is sent.
Carry agreements into the next interaction
The account record should preserve the result of the review without turning discussion into commitment. Suppose the customer confirms who will provide the missing integration input but cannot yet agree on a date. In the continuing illustrative workflow, Iris would update the milestone draft with the confirmed responsibility and keep timing open. A complete-looking schedule would be less useful than an accurate statement of the unresolved decision.
If the call changes the understanding of the blocker, the revised brief would need to change with it. An integration thought to be essential might prove unnecessary for the customer's immediate objective. The old note would still explain why the team previously waited, but the next agenda should use the new agreement. Preserving working history means distinguishing what applied earlier from what now guides the account.
The follow-up would then become a reference for the next conversation. It should make the customer's and team's commitments understandable without relying on someone's memory of the call. An unanswered question should remain visible beside the agreement it affects. This helps the next manager avoid interpreting silence as completion or promising that a dependent milestone is ready when its prerequisite is still unresolved.
The same account history supports a handover when ownership changes. Iris's proposed transition brief would retain goals, contacts already recorded in the CRM, the onboarding sequence, open decisions, and the next scheduled action. In this example, the receiving manager would need to understand both the integration dependency and the review that clarified it. A list of current tickets alone would omit why the team chose its next step.
The receiving owner would also need to know which statements remain uncertain before repeating them to the customer. A former owner's proposed date, an unconfirmed workaround, and a customer's request have different meanings. Keeping their status visible allows the new owner to continue the relationship without accidentally converting inherited notes into fresh promises.
Use the account history for renewal preparation
Renewal preparation brings the timeline and commercial questions together with adoption evidence and outstanding commitments. Iris's model would give the responsible manager a discussion brief rather than automatically offer a discount or change terms. The account's earlier onboarding objective provides a reference for asking whether the customer reached the outcome they expected.
Later in the same illustrative account story, completing the integration would establish that a prerequisite was addressed. The renewal brief would still need evidence about the working process it enabled. If the available record showed only setup completion, the manager would need to ask whether the customer had adopted the intended workflow. Closing a technical issue and demonstrating customer value are different parts of that review.
Outstanding commitments would sit beside that adoption evidence. The customer may have received help with the integration while still waiting on a separate answer documented during onboarding. The brief would preserve that open item so the renewal conversation does not present the relationship as fully resolved merely because one prominent blocker disappeared.
The timeline also affects preparation. A near-term renewal can make an unanswered commercial question urgent, but it does not establish that pricing is the cause of an account concern. Iris would organize the questions and known constraints for the authorized owner. The manager would decide what to discuss with the customer and which commercial options are available within their authority.
This creates a specific use for the accumulated history: the manager can connect the original objective, the work completed, the evidence of adoption, and the promises still outstanding.
Give product the underlying need without a roadmap promise
Support-to-product synthesis groups recurring account problems by underlying need and retains representative examples. In the continuing walkthrough, the integration difficulty might also generate a request for a product change. Iris would preserve what the customer was trying to accomplish and what blocked that work, so the product team can assess the need behind the requested solution.
A feature request and a delivery commitment must remain separate. If the customer asks for a change during the review, that request can enter structured product feedback. Inclusion in the account brief or renewal notes does not mean the product team has accepted it, assigned it, or promised a date. The account manager needs to know that status before using it in a customer conversation.
The evidence should also preserve the relationship between repeated records. Several follow-ups about this one account's integration would show persistence of the same problem; they would not establish that several customers independently requested the feature. Representative examples would give product enough context to examine the workflow without overstating how widely the need has been observed.
The proposed output would connect the account problem to the product request and retain any approved answer for later account preparation. This lets the customer success team ask for a product decision while keeping the customer's current onboarding agreement usable. A possible future capability should not silently become a prerequisite for work the parties already agreed could proceed.
Keep preparation inside the account team's permissions
Potential connections include the CRM, selected support conversations, account-level product analytics, and an approved product knowledge base. Customer information stays within the account team's permissions. The preparation workflow produces drafts and internal updates; external messages, pricing commitments, contractual changes, and roadmap dates remain with the authorized owner. Any broader action workflow would need its own design and authorization.
Evaluate Iris with a defined account segment and have its owners review every brief. Track preparation time, corrections needed, onboarding milestones completed, and commitments carried into the next meeting. Review whether the brief correctly identifies missing context as well as whether it includes known facts. An unsupported explanation of low usage can waste the meeting even when the summary is otherwise accurate.
For the illustrated account review, the team estimates around 20 minutes of the account owner's time to check the brief, confirm the flagged statements, and finalize the agenda, against roughly 100 minutes of reading the CRM, tickets, analytics, and notes by hand: around 5× faster preparation. This is a modeled estimate for one review, not a measured result.
No measured retention effect is claimed. Renewal and retention changes need a longer observation period than a few successful conversations, with account circumstances considered alongside the assistant's contribution. For the onboarding workflow, an immediate test is whether the owner enters the review knowing the documented dependency and leaves with an accurate, reviewable account of what the customer actually agreed to do next.