Account Management Modes
Account Management Modes
The AM role is not static. While the AM is always responsible for the health and continuity of their client relationships, the nature of that work shifts depending on what is happening with each account at any given time.
We describe these shifts as modes. At any point, an AM may be in one or more of the following modes with a given client:
- Steady state — the default. No active project. The AM maintains the relationship, monitors health, spots opportunities, and keeps things moving.
- Opportunity in play — something has been raised that might become a project. The AM qualifies it and prepares a handoff to New Work. This aligns with 'Pre-project' in the Project Playbook.
- Project underway — a project is active. The AM steps back from day-to-day delivery but stays relationally present and is ready to step in if needed.
- Transition — a project is wrapping up. The AM steps back in, runs the retrospective, picks up the backlog, and resets to steady state.
Recognising which mode you are in, and adjusting your approach accordingly, is one of the core skills of account management at Agile Collective. The sections below describe each mode in detail, starting with steady state.
Steady State (business as usual)
The steady state is the default condition of an account: there is no active project or ongoing conversations. Your job is to keep the relationship healthy, stay informed, spot opportunities, and make sure nothing falls through the gaps.
Most of your client relationships will be in steady state most of the time. This is not a passive mode — it requires ongoing and proactive attention.
Rhythm
Good steady state account management follows a clear rhythm. The frequency of contact varies by client, but the structure is consistent.
Annually — Once a year, produce an account review for each client using the standard template. This should cover:
- A summary of work delivered over the past year
- Support activity and trends
- Recommendations for the year ahead
- A proposed plan and priorities going forward
Share this with the client and offer a meeting to discuss it. Some clients will want that conversation; others will be happy to receive it in writing. Either way, it should happen.
The annual review does not need to fall in January or at the start of a financial year — align it to whatever cycle makes sense for the client. The important thing is that it happens consistently.
Quarterly — High-value clients, clients experiencing difficulty, and any client with ongoing project activity should have a quarterly check-in. This can be as short as twenty minutes. The focus is on:
- Reviewing the roadmap
- Checking in on priorities and any changes in their organisation
- Identifying anything that needs attention
Monthly — For clients without a monthly meeting cadence, stay visible in the support system. Review open tickets, check for anything that needs flagging, and make sure nothing is drifting. This does not require initiating a client meeting — it is about maintaining awareness and being present.
Weekly — Each week, scan your client portfolio and ask: who needs attention right now? If you are running a quarterly cycle across your accounts, you should expect to be actively focused on a different client most weeks. Use this scan to:
- Identify clients who are overdue contact
- Spot anything in the support system or inbox that needs a response
- Flag anything to relevant internal teams
- Check upcoming meetings and prepare accordingly
Weekly rhythm is about portfolio awareness, not client-by-client weekly contact.
Ad hoc
Not everything fits the rhythm. Alongside your regular cadence, you will need to respond to things as they arise. Common triggers include:
- A client raises something in a meeting or email that suggests a new need or project
- The Support team flags something that is growing beyond a standard ticket
- A client stakeholder changes, leaves, or a restructure is announced
- A client expresses dissatisfaction or concern
- You notice a pattern — such as missed responses, reduced engagement, repeated issues — that suggests a relationship needs attention
When something is raised (whether directly by the client, by Support, or a PM) it comes to you first. Your job is to assess it and decide what happens next.
Handling new feature or project requests
When the Support PoC receives something that looks like more than a support ticket, they should pass it to the AM. The AM then assesses whether it:
- Can be handled within existing support
- Needs a conversation with a specialist (designer, developer, UX, accessibility etc), in which case the AM sets that up
- Represents a genuine project opportunity, in which case you should gather the following information and pass on to New Work
The AM does not need to estimate or scope the work. The AM's job is to make sure the right information is gathered before anything goes further. Nothing should reach New Work as a half-formed request.
- What the client is trying to achieve (Aims)
- What they think they want (Suggested solution)
- Budget expectations (even a rough sense)
- Timeline
- Any relevant constraints — technical, organisational, or historical
See the New Work Handoff Template.
Escalation
Some situations require you to act quickly and bring in others. The following are triggers for escalation:
- A client expresses serious dissatisfaction or raises a complaint
- A key stakeholder leaves (or is going to leave) and the relationship becomes uncertain
- A client signals they may be considering leaving
- Client behaviour is becoming harmful to the Agile Collective team
- You notice a pattern of disengagement that is not resolving
When any of these occur, do not wait for the next scheduled meeting or check-in. Escalate promptly to the relevant lead or the Delivery Circle, depending on the situation. Refer to the escalation table in this playbook for guidance on who to involve.
Your role in escalation is to surface the issue clearly, coordinate the response, and protect the client relationship. Resolution of technical or delivery problems remains with the relevant teams — but you own the relationship through the difficulty.
Note on where opportunity handling sits: when a client raises something that eventually becomes a project, the AM's role in gathering and routing that request sits within steady state. However, once the opportunity is confirmed and handed to New Work, it formally enters Pre-project as defined in the Projects Playbook. At that point the AM shifts mode. We have kept the routing guidance here because that is where the AM first encounters it — but be aware it connects directly to the Projects Playbook from that moment on.
Opportunity in Play (Pre-Project)
This mode begins when a potential project has been identified and the AM has completed an initial assessment. It ends when the opportunity is either handed to New Work or dropped.
Triggers
- A client raises something during steady state that looks like a project
- The Support PoC routes something to the AM that has grown beyond a support ticket
- A roadmap or annual review conversation surfaces a clear need
What the AM does
- Assess whether this is actually a project opportunity or something that can be handled within existing support. If it's the latter, route it accordingly and return to steady state.
- If it does look like a project, gather the information needed for a clean handoff using the New Work Handoff Template: what the client is trying to achieve, what they think they want, budget expectations, timeline, and any relevant constraints or history.
- Pass the completed template to New Work. From this point, New Work owns the proposal and estimation. The AM is kept informed of what the proposal looks like but is not responsible for producing it.
- Once the proposal is with New Work, this mode ends. If the project is confirmed, the AM moves into Project(s) Ongoing mode at Mobilisation. If the opportunity does not progress, the AM returns to steady state.
Project(s) Ongoing (Mobilisation to Delivery)
This mode begins at Mobilisation, when the PM formally takes ownership of delivery. The AM steps back from day-to-day involvement and the PM drives the work.
The AM does not disappear entirely: they remain relationally present, available to the client, aware of how things are going, and ready to step in if there is a relationship issue that needs attention.
What the AM does
- Liaises with the PM about the background and/or attends the internal project kick-off to ensure a clean handover and to signal continuity to the client
- Maintains a regular sync with the PM (e.g. fortnightly for longer projects) to stay informed of progress, risks, and anything client-facing that needs attention
- Continues any routine AM meetings with the client that were in place before the project started, coordinating with the PM to ensure messaging is consistent and nothing is duplicated or contradicted
- Acts as the escalation point if a relationship issue arises during delivery
What the AM does not do
- Manage day-to-day delivery or project tasks
- Get involved in technical decisions
- Duplicate the PM's client communications
Where there is any ambiguity about roles or process, the Projects Playbook is the authoritative reference for the project side, and this playbook covers the AM's role within it.
Transition
This mode begins when the project is wrapping up. The PM should flag this to the AM in good time.
What the AM does
- Takes part in (or facilitates) a client-facing review of the project within four weeks of it ending, and documents high-level learnings
- Reviews the project backlog with the client, helps them prioritise, and supports them in converting items into support tickets (or remaining in a separate backlog for now)
- Resets the relationship rhythm and resumes steady state meetings
- Updates the AM Master Sheet/CRM with any changes to priorities, stakeholders, or health status
Once the backlog has been reviewed and the regular meeting cadence is re-established, the AM returns to Steady State.
Last updated: