Company Brain for ERP handover to support

An answer for the consultant handling the ticket

Suppose a customer proposed removing manager approval for purchase orders during a workshop. A consultant recorded the idea in the meeting notes. Later, the agreed handover document stated that the version deployed for the customer retained manager approval. Removing it was still a proposal. The documents give no reason for postponing the change or a date for implementing it. The support consultant can access both records and knows which version the customer is asking about.

In this example, the assistant might answer: “Manager approval was retained at go-live. The system handover document confirms this and lists removal of that step as a proposal.” Links alongside the answer let the consultant open the handover document and workshop notes.

The consultant can now explain to the customer what was agreed at go-live. The consultant can ask the project lead why the change was postponed and whether a decision has since been made to implement it. There is no need to reconstruct the entire workshop first. The consultant decides how to respond to the customer and whether the ticket also calls for checking the ERP system itself.

Here, the assistant is reporting what the documents say. If someone later changed the settings without updating the documentation, the knowledge base would not establish that. A consultant with the appropriate system access can check how purchase orders are handled today. The documented handover gives that investigation a starting point.

What to hand over with the working system

Support needs enough of the project's history to understand the system delivered and the issues still open. The workshop notes alone could lead a consultant to think manager approval should already have been removed. The handover document explains what was agreed for the version deployed for this customer.

Microsoft's Dynamics 365 guidance on transition and handover recommends documenting project decisions and changes and including them in the knowledge transferred to support. That handover practice also provides a basis for deciding what belongs in an assistant's library.

The implementation lead should identify the document describing the deployed version and the person who will update it after subsequent changes. Open proposals need to be distinguishable from completed work. Support also needs to know who handles questions about changes to scope. The author of an old message may no longer be responsible for the decision.

Answers should follow the consultant's access to customer projects. If a particular implementation produces a lesson worth sharing with other teams, prepare and approve that summary separately. Removing the customer's name from a note does not establish that everything else in it can be shared across the firm.

A better handover or a knowledge assistant?

If consultants mainly need one handover document, a clear project page or folder with the right links may be enough. If the records are incomplete, improve the handover first. AI cannot recover a decision the implementation lead never recorded.

Also consider whether support had a chance to work with the system before taking over tickets. Microsoft's guidance on Dynamics 365 support operations recommends involving support in project activities and practicing support processes during later testing. Those exercises help the team learn the system before it takes responsibility for customer support.

A separate assistant has a stronger case when answering a question regularly means combining a handover document, an earlier agreement, and a later change request. A case like the manager approval question is useful for a purchasing discussion. After reading the answer, a consultant who was not on the implementation team should be able to explain what the records say was deployed and what still needs clarification. The project lead can check whether the assistant has represented the agreements correctly.

A first library with Syntalith

Syntalith builds Company Brain applications that help people find answers in their organization's knowledge. For an ERP handover, an initial scope could cover the documentation for one implementation. Once we agree on the scope, we can connect handover records with project decisions so a consultant can ask about a specific issue and receive an answer linked to materials they are allowed to read. The implementation team would check the answer against the agreements, while support would judge whether it helps them handle the ticket.

To start, describe one situation where support had to go back to an implementation consultant and explain where the relevant information is stored today. You do not need to send customer documents or prepare a full specification. See Syntalith's pricing page for commercial information. For a related problem of finding documentation that matches the system being serviced, read about Company Brain for multi-brand technical service.