Preparing Customer Service for an ERP Go-Live. Rehearse customer questions, difficult cases and escalation.
During an ERP transition, a customer rarely asks which process changed. They ask where the order is, why an invoice looks different, or when a return will be resolved. A service representative needs a reliable answer even when the work crosses several teams and the system status is unfamiliar.
Prepare a customer-impact scenario pack before launch. For each consequential exception, define the evidence the representative should inspect, what can safely be explained, what may be promised, who owns the next action, and when the customer will receive another update.
The goal is a trustworthy conversation followed by controlled action. A polished script cannot compensate for an unknown order state or an unowned escalation. Build the evidence and ownership behind the words, then rehearse the complete route from the first question to resolution.
Review the changed order, fulfillment, invoice, payment-status, return, and account-service processes. Identify points where the customer may see a different document, reference number, status, timing, or contact route. Also identify temporary arrangements during the transition.
Use existing service cases and frontline knowledge to select scenarios. Concentrate on situations where an inaccurate answer could create a broken promise, duplicate work, financial confusion, or an avoidable repeat contact. A rare but consequential exception may deserve more preparation than a frequent question with an obvious answer.
Write scenarios in the customer's language. “My shipment is incomplete” gives a clearer starting point than an internal status code. Underneath that question, list the possible business states: a planned partial shipment, a hold, a short pick, a timing difference between systems, or an incorrectly recorded quantity.
Do not assume that all unfamiliar statuses represent a defect. The scenario pack should help representatives distinguish an expected process state from missing evidence or a genuine failure.
Define where the representative should verify the relevant fact. Order acceptance, physical dispatch, delivery confirmation, invoice issuance, and receipt of payment are different events. A status in one area may not prove the event the customer is asking about.
For each evidence source, record what it establishes, when it is updated, and any known limitation. If a carrier confirmation arrives later than warehouse dispatch, the representative needs to understand that distinction. If a transition report covers only transactions before a cutoff, it should not be treated as a complete view of current work.
Set a route for conflicting evidence. The representative should know which owner can reconcile a mismatch and what information to provide. They should not choose whichever status produces the most reassuring answer.
Keep access appropriate to the role. Representatives need enough information to resolve the customer's question, but the playbook should not encourage sharing unrelated internal records or personal data. Apply the organization's identity-verification and disclosure procedures before discussing account-specific information.
An explanation describes what is known. A promise commits the organization to a future action or outcome. The playbook should make the boundary visible, especially when dates, credits, replacements, or exceptions require another team's approval.
For example, a verified record may support saying that an order is awaiting an approved release. It may not support promising dispatch that afternoon. A representative can commit to providing the next update at an agreed time if the organization has a process and capacity to honor that commitment.
Define permitted commitments by role. Include who may authorize a changed delivery date, a replacement, an expedited service, a credit, or another remedy. Use the organization's approved commercial and control rules; the transition should not silently create new discretion.
Prepare language for uncertainty that remains useful. State the verified fact, identify what is being checked, name the responsible team in customer-appropriate terms, and provide the next update arrangement. Avoid exposing unnecessary internal detail or blaming the customer, another department, or the system without evidence.
Keep the working card short enough to scan while the conversation continues. Link to detailed procedures rather than reproducing every step. Each card should contain:
Use a case identifier or equivalent record that follows the issue across teams. The customer should not have to restart the explanation each time a specialist becomes involved. The record should preserve verified facts, prior commitments, and the next action without accumulating unnecessary personal information.
Where a representative cannot access the required evidence, define a viable alternative route. An instruction to “check the relevant record” is unusable if the role has no approved access and nobody is assigned to respond.
Practice with the teams that must act on service escalations. A service representative may recognize a hold correctly while the receiving team lacks the context or authority to resolve it. Test both sides of the handoff.
Ask the receiving owner to confirm what a complete request contains. For a disputed invoice, that may include the relevant transaction reference, the disputed element, what the customer says is incorrect, and the evidence already checked. The exact requirements should follow the organization's process and data rules.
Verify the route during actual operating hours. A named specialist who is unavailable when the service team works creates an unresolved dependency. Define backup coverage and urgent handling for consequences that cannot wait until the next routine review.
Rehearse an unanswered escalation as well as a successful one. The representative needs a route when the expected owner does not respond, when teams disagree about ownership, or when the customer's requested outcome exceeds delegated authority.
Consider a hypothetical customer who ordered several items and received only part of the order. The representative sees an overall order status that could be mistaken for complete fulfillment. A detailed dispatch record shows which items left the warehouse, while the remaining lines have a different state.
The scenario card directs the representative to verify line-level fulfillment before explaining the situation. It distinguishes what has shipped from what remains unresolved and identifies the owner who can confirm the remaining availability and release conditions.
The representative can explain the verified partial shipment and arrange the next update. A revised delivery commitment requires the designated operations owner to confirm that the remaining goods and transport arrangement support it. If the customer asks to cancel the remainder, the request follows the approved cancellation and fulfillment checks before action.
The rehearsal should test whether the handoff preserves the customer's request, whether the next owner acknowledges it, and whether the promised update occurs even if the final answer is still pending. This example is illustrative; the evidence and authority will depend on the business's own process.
Assign an owner to each scenario and a coordinator for the overall knowledge pack. Decide who can approve a changed explanation and how frontline staff will recognize the current version. A hurried correction in a message thread should not become the only place where the right answer exists.
Use incoming cases to identify missing scenarios and unclear instructions. Separate a new business rule from a temporary issue and from a clarification of an existing rule. Each needs a different review and communication path.
When an explanation changes, check open cases that may have received the earlier guidance. The case owner should determine whether an update is needed. Correcting the knowledge article alone does not address a customer who is still relying on an outdated promise.
Retire temporary instructions deliberately. Record what replaces them and preserve any history needed to understand past cases. Old and new playbooks should not remain equally discoverable without a clear indication of which one applies.
Review whether answers were accurate, commitments were authorized, actions had owners, and updates occurred as agreed. Pair workload measures with evidence of customer outcomes. A short contact can look efficient while leaving the issue unresolved and generating another call.
Use representative case reviews to examine repeat contacts, disputed explanations, missed updates, and inappropriate promises. These may indicate a knowledge gap, a capacity problem, an unclear process, or unreliable status information. Route the cause to the owner who can change it.
Track pending cases through the transition boundary. A return started before launch may need action afterward. An invoice dispute may span old and new references. The playbook should explain how those cases remain visible and how duplicate action is prevented.
Before day one, take a handful of consequential customer questions through the entire route. Confirm the evidence, the explanation, the authorized action, the receiving owner, and the follow-through. That rehearsal gives frontline teams something more useful than reassurance: a credible way to help the next customer.