Managed Services Starts Before Go-Live

The question is why managed services so often enters the conversation too late. By the time a cloud ERP program is near go-live, the client is tired, the delivery team is focused on stabilization, and executives are already turning to the next problem. Support is then framed as maintenance, not as a continuation of business improvement.

What’s at stake is not just post-implementation revenue. It is whether the consulting organization stays close to the client after the system is live, when the harder questions begin: adoption, process ownership, reporting discipline, automation, operating model changes, and the practical use of AI. These are not separate from delivery. They are the next phase of delivery.

From first principles, managed services should be introduced when there is enough trust to discuss future needs, but before the client has mentally closed the project. That timing requires pipeline discipline, executive coverage, and a clearer way to connect support work to strategic outcomes.

The Pipeline Is a Timing System

A managed services pipeline is often treated as a list of accounts. That is useful, but incomplete. The more important view is timing.

In one recent pipeline review, a managed services representative and a managing director walked through several active cloud ERP projects. The managing director was not in the daily project details, but he remained closely connected to finance executives across the accounts. That mattered. He could read the client relationship, understand executive priorities, and identify when a support conversation would feel helpful rather than premature.

Most of the active projects were still early. Some were in design. Others were working through configuration, data, or process decisions. A few were approaching the point where stabilization planning would soon become relevant. The result was not an immediate sales list. It was a calendar of likely windows.

That distinction matters. Managed services introductions should not happen only when the project manager remembers to mention them. They should be tied to observable project stages:

Early design: listen for complexity, gaps in internal ownership, reporting needs, and process friction.
Mid-implementation: identify areas where the client will need recurring help after go-live.
Pre-go-live: introduce continuity planning, support models, and improvement roadmaps.
Stabilization: convert urgent support into structured backlog management.
Post-stabilization: shift from issue resolution to optimization and automation.

This is a simple system, but it changes the conversation. Instead of asking, “Which clients can we sell support to?” the better question is, “Which clients will soon need continuity, and who has the trust to open that discussion?”

Coverage Is a Design Problem

The pipeline review also surfaced a common consulting problem: coverage gaps. Delivery leaders may know the system. Managing directors may know the executive relationship. Managed services teams may know the post-go-live offering. AI specialists may know the emerging use cases. But the client experiences only one firm.

When these groups operate separately, opportunities disappear between them. A client mentions a reporting bottleneck in a steering committee. The delivery team logs it as a future enhancement. The managed services team never hears it. The AI team later pitches a tool without knowing the process context. No one is wrong, but the system underperforms.

The remedy is not more internal meetings. It is clearer handoff logic.

A useful client coverage model answers four questions:

Who owns the executive relationship?
Who understands the operational pain?
Who can translate that pain into a support or improvement model?
Who is responsible for the next conversation?

This is especially important when the managing director is not involved in day-to-day execution. Senior leaders often have the best access to CFOs, controllers, CIOs, and transformation sponsors. They may not know every configuration issue, but they know whether the client is anxious, under-resourced, expanding scope, or looking for a broader partner.

Managed services teams need that signal. Without it, they enter late and cold. With it, they can prepare a relevant point of view.

Support Is Not the Same as Strategic Continuity

One tension in the discussion was that managed support is often undervalued by clients and underrepresented internally. Clients may hear “support” and think of ticket queues, minor fixes, and break-fix work. Internal teams may see it as a lower-margin or less visible continuation of the project.

That framing misses the real value.

After implementation, the client’s operating model is still forming. Users are learning new habits. Finance teams are testing close processes. Leaders are discovering which reports they trust and which ones they do not. Workarounds begin to appear. Backlogs grow. Governance gets informal.

This is the period when a consulting partner can either fade away or become more useful.

Managed services should be positioned around continuity, not dependency. The message is not, “You will need us because the system is complicated.” The message is, “You have invested in a new platform. Now we can help you convert that platform into a more stable, measurable, and adaptive way of working.”

That may include:

issue triage and release management
report rationalization
process improvement backlog management
integration monitoring
finance close support
training reinforcement
automation discovery
AI use case development
governance cadence with business owners

The strategic value comes from connecting these activities to business outcomes. Fewer manual reconciliations. Faster close. Better adoption. Cleaner data. Lower operational risk. More reliable executive reporting.

AI Should Start With Process, Not Tools

The AI portion of the conversation sharpened the point. A participant pushed back on leading AI conversations with tool demos. The concern was practical: AI without a process strategy has little value. It may impress in the moment, but it does not create durable client impact.

This is an important discipline for consulting teams. AI sales motions can become too abstract or too product-led. Clients are shown a chatbot, a document summarizer, or a workflow assistant before anyone has mapped where work actually gets stuck.

A better starting point is process discovery.

One working model discussed was a two-and-a-half-hour discovery session. The purpose is not to sell a specific tool. The purpose is to find repeatable work that is manual, measurable, and meaningful enough to improve.

A practical session might follow this structure:

1. Map the Work

Start with a function or process area, such as accounts payable, financial close, procurement intake, revenue recognition, project accounting, or management reporting. Ask the client to walk through how work happens today, not how it is documented.

Look for handoffs, spreadsheets, email approvals, duplicate data entry, judgment calls, and recurring exceptions.

2. Identify Repeatable Friction

AI and automation are most useful where work repeats and consumes attention. The target is not every annoyance. It is work that happens often enough to matter and is structured enough to improve.

Examples might include:

matching invoice data against purchase orders
summarizing contract terms for review
drafting variance explanations
classifying support tickets
preparing close status updates
extracting information from vendor documents
routing requests based on policy rules

3. Size the Opportunity

The conversation should move quickly from possibility to economics. How often does the process run? How many people touch it? How long does it take? What errors or delays does it create? What would improve if cycle time dropped by 30 percent?

This does not require a perfect business case. It requires enough sizing to separate useful AI work from interesting distractions.

4. Build a 30-60-90 Day Roadmap

The output should be a short, sequenced plan. In the first 30 days, confirm the process and data. In 60 days, prototype or configure the improvement. In 90 days, measure results and decide whether to scale.

This gives executives something concrete. It also gives managed services teams a way to stay involved after go-live, where many of these process improvements become visible.

The Risk of Invisible AI Work

Another concern was that AI work can disappear into support tickets. A client asks for help. A consultant uses AI to speed analysis, draft a response, classify issues, or automate a small step. The client receives value, but the firm does not capture the story. The work becomes invisible.

This creates two problems. First, the client may not understand the improvement they are receiving. Second, the consulting organization may fail to build a repeatable service line because the learning remains buried inside individual tickets.

The answer is not to overpackage every small AI use. It is to create light visibility.

Managed services teams can track:

where AI assisted delivery
which client processes were improved
how much time was saved
what patterns repeat across accounts
which use cases deserve a formal offering

This turns scattered support activity into market learning. It also helps practitioners see which AI use cases are grounded in real client work.

Turning a Sync Into a System

The practical follow-ups from this kind of meeting are straightforward, but they require consistency.

For each active implementation, the team should assign:

a likely managed services introduction window
the executive sponsor or relationship owner
the delivery contact who knows the operational issues
the top two post-go-live risks
any AI or automation discovery candidates
the next internal action

This can be maintained as a lightweight account view. The point is not administrative completeness. The point is shared awareness.

The managed services representative should not have to chase context account by account. The managing director should not have to remember every timing window from memory. Delivery teams should not have to decide alone when to introduce post-go-live support. A simple shared system reduces dependence on heroics.

It also improves the client experience. When the conversation happens at the right time, with the right context, managed services feels less like an add-on and more like continuity.

What Leaders Should Watch

Executives should pay attention to three signals.

First, whether post-implementation support is being discussed before the final project phase. If not, the firm is likely waiting too long.

Second, whether AI conversations are tied to specific processes and measurable work. If not, the sales motion may be too tool-led.

Third, whether account coverage is clear across delivery, managed services, and senior relationship owners. If not, valuable client signals are likely being lost.