Recover adoption when managers bypass an MSP workflow

Managers sometimes look for an email shortcut when a vendor management workflow feels slow or confusing. A client success manager should listen for the specific point of friction while preserving the approval route selected by the program. An email request might feel faster in one moment, yet bypass manager and finance review. Recovery begins with a clear description of where requests stop, who sees each status, and which team owns the next decision.

Start with examples from a recent period. Ask the program director for a few request dates, current statuses, and the names of the roles involved. Keep candidate information out of a broad troubleshooting thread. The purpose involves understanding workflow use, not collecting every detail inside a request. A simple review table, held by the authorized account team, might show request date, request stage, visible rejection reason, training attendance, and owner for follow up. Each entry should answer one operational question.

Ask a manager to describe the last request step by step. Do not begin by asking whether they like the system. A broad opinion rarely identifies an action. Instead ask, “When you opened the request on Tuesday, what did you expect to happen next?” Follow with, “Which field or status stopped you?” Then ask, “Who did you contact, and what happened after your message?” Their answers reveal whether the issue involves training, access, unclear wording, status visibility, or a delay in another approval stage.

Keep separate problems separate. A manager who missed the initial training session might not know why a field matters. A manager who completed training might understand every field yet lack visibility into a rejected request. One issue calls for targeted help from the training owner. The other calls for review by the MSP or program team responsible for system configuration and status handling. Treating both as a single adoption issue produces a vague plan and leaves people waiting.

Use a fictional account situation to guide the conversation. Program director Marta tells client success manager David, “Managers are sending requests by email because the new route takes too long.” David replies, “The program route includes manager and finance approval. Email would skip steps your program chose. Let us look at where requests pause and what managers see there.” Marta says several managers missed training, while others say a rejected request disappears from their view. David records two separate issues instead of promising one broad fix.

David asks Marta for four recent requests. One manager submitted a request on Monday and stopped after a required field appeared unfamiliar. A second manager submitted on Tuesday, received a rejection, and saw no clear explanation in the view available to them. A third request waited for finance review. The fourth request had no issue. The four examples show why email would hide useful differences. The first needs instruction. The second needs a status visibility review. The third needs program follow up on an approval stage. The fourth gives the team a working path for comparison.

During the account review, David asks who owns each next step. Marta names Priya from the MSP team for the rejected status view. Marta names Calvin from program training for a short session with managers who missed the original session. Marta keeps responsibility for deciding whether finance approval timing requires a change inside the program. David confirms who will contact each person, what example they need, and when the group will review progress. A name, a date, and a question prevent an action item from fading into a meeting note.

The conversation should state why email is unsuitable without blaming managers. David might say, “I understand why an email feels direct when a request looks stuck. The request route gives finance and program owners a place to review before work begins. Let us make the route easier to use and easier to understand.” This language recognizes the manager’s pressure while holding the boundary. Avoid saying a manager should have known better. The recovery needs their specific experience.

Targeted help works best when tied to a task managers need to complete. Calvin might invite the missed group to bring a fictional request scenario. He asks each person to enter the request purpose, select the appropriate approval information, and read the status after submission. If a field remains unclear, Calvin records the question for the program owner instead of guessing. A short session built around the exact blocked step gives managers a chance to use the route while support is present.

For the status visibility issue, Priya needs a narrow example. David sends the request reference through the approved account channel with the date, manager role, visible status, and the question Marta wants answered. Priya reviews whether a rejected request has an explanation available to managers and whether the program wants a different communication method for rejections. Priya owns the system review. Marta owns the program decision. David keeps the account conversation organized and shares the agreed route with staffing contacts.

Agree on measures before calling recovery complete. Marta might want to review the number of requests submitted through the approved route during the next two weeks, the number of managers who attended targeted help, and the number of requests where a manager reports an unclear status. Those measures describe use and friction. They do not promise faster approval or a fixed outcome. Ask Marta which measures matter for her program and who will review them. Use the answer as the next meeting agenda.

Avoid a large announcement filled with new instructions. Managers need one clear route for a request and one clear contact for a question. Send a concise message after Marta approves the language. State where requests belong, explain whom to contact when a field or status blocks progress, and name the targeted help session for managers who need support. Do not place candidate details in the message. Do not describe a system issue as solved before Priya finishes her review.

If managers continue using email, inspect the newest examples. A manager might be under a deadline and lack access. Another manager might be repeating an old habit from before the program launch. A third manager might still fail at the same field after training. Each case calls for a different conversation. Ask what they tried, where the route stopped, and who should respond. Repeating a general reminder without this detail rarely changes the behavior behind the email.

Practice with a fictional request moving from manager entry to finance approval. Put a training issue into the fictional manager’s first attempt. Put a separate visibility issue into the next attempt. Ask a colleague to play Marta and request an email workaround. Explain the approval boundary in plain language, then assign the training question to Calvin and the visibility question to Priya. State the example each owner receives and the review date.

Finish the practice by opening a blank follow up note. Write the fictional request date, current stage, owner, next action, and review time. At the review time, mark whether the manager used the approved route, whether training occurred, and whether the status question reached Priya. Use those notes to choose the next conversation with Marta.