Three months after an SAP ® go-live, the calls start. An AR clerk cannot post a vendor invoice because the new payment terms validation is throwing an error nobody recognizes. A buyer cannot complete a purchase order release strategy because the approval chain points to someone who left the company. A controller cannot work out why the new cost center hierarchy is splitting variances differently from the legacy report. Each question takes the SAP consultant a few minutes to answer. Each answer should have lived in a place the client team could find without picking up the phone.
For a smaller specialist SAP consultancy or a freelance consultant working module by module, those calls represent a real cost. Some of them are billable. Most of them are unbillable goodwill that erodes margin and signals to the client that the engagement is not really finished. The pattern is so common that many consultants build retainer hours into every contract just to absorb it.
The cause is rarely the SAP configuration. The cause is that the documentation produced during the implementation was written for IT and the project team. End users were left to find their own way. Solution Manager has the technical record. The client’s shared drive has stale PowerPoint training decks. The consultant has the answers in their head. None of that helps the AR clerk on a Tuesday morning.
This guide is for SAP implementation consultants who want to fix that pattern. It covers why end-user documentation is uniquely hard in SAP work, what Whale gives a consultant during and after the project, five practical use cases that show up on almost every engagement, and how the Whale Partner Program rewards the recommendation.
Why SAP implementation documentation is uniquely hard
An SAP implementation produces a particular kind of documentation challenge. The system is built around transactions, configuration tables, and master data, but the people using it think in business activities: invoice the customer, receive the goods, run payroll, close the books. Translating between those two languages is the entire job of the documentation, and most projects do not invest enough in it.
The first reason is audience separation. Solution Manager is the right home for the technical record (configuration decisions, custom development specs, integration logic, test scripts). End users do not open Solution Manager. They need a different layer of documentation, written in their language, accessible without IT support, and tied to the moments where they actually need help.
The second reason is the gap between training and operating. The training delivered at go-live, no matter how thorough, fades within weeks. Three months after training, the AR clerk has forgotten the steps for the rare scenarios. Six months after training, a new AR clerk has joined who never attended the original session. Without documentation written for daily reference rather than initial training, the knowledge erodes.
The third reason is the why problem. Every SAP implementation includes hundreds of small decisions: why the document type is set up this way, why the validation rule is configured to block this scenario, why the workflow routes approvals through this group. Six months later, when someone wants to change something, the why is what matters most. It is also the part of the documentation that almost never gets written down. The consultant carries it in their head, and the client pays for the consultant’s memory in retainer hours.
The fourth reason is decay. An SAP environment, whether ECC or S/4HANA ®, changes constantly. Configuration updates, master data extensions, custom report revisions, year-end close adjustments. Documentation that was accurate at go-live drifts out of date inside three months if there is no mechanism to keep it alive. Most projects do not have a mechanism.
For a smaller specialist consultancy, these compound. The freelance MM consultant working with a midmarket manufacturer does not have a twenty-person change management team. The two-person FI/CO firm does not have a documentation specialist on staff. The cost of weak end-user documentation lands on the consultant directly, in the form of post-go-live calls that should have been answered by the documentation itself.
Why the obvious options fall short
The first option most projects reach for is SAP Solution Manager. Solution Manager is excellent at what it was built for: technical configuration records, transport management, integration testing, operational support documentation. The product was not designed for end-user documentation. The vocabulary is wrong for the audience, the access model is wrong, and end users do not have the patience to navigate it. Treating Solution Manager as the home for end-user SOPs sets the team up for non-adoption.
The second option is the SAP Help Portal and SAP Learning Hub. Both are valuable for learning the standard SAP product. Neither documents the specific client implementation. SAP Help Portal explains how transaction ME21N works in general. It does not explain why this client’s release strategy on ME21N is configured the way it is, or what the AR clerk should do when the validation rule on FB60 blocks an invoice posting.
The third option is general-purpose collaboration tools like Confluence or SharePoint. These are flexible enough to hold the content, but they sit outside the work, do not enforce ownership of documents, do not flag stale content, and have no training infrastructure. A Confluence page documenting the month-end close routine is a page until someone deletes it or forgets it exists. Six months later, the team has stopped trusting it.
The fourth option is the PowerPoint training decks produced for go-live. These are useful on the day they are delivered. By the time the AR clerk needs to refresh their memory in week fourteen, the deck is in a folder nobody can find, several screenshots are out of date, and the deck does not cover the scenario the clerk is actually facing.
The fifth option is the consultant’s own notes. Most experienced SAP consultants keep notes in Notion, OneNote, or a personal wiki. Those notes are excellent for the consultant, but they are the consultant’s property rather than the client’s. They cannot be handed over without losing the structure and context that make them useful. The client team starts from zero.
None of these options solve the actual job: end-user documentation that is found in seconds, written in business language, kept alive after the consultant rolls off, and tied to the moments where the user needs help.
What Whale gives an SAP implementation consultant
Whale is built around a different assumption. End-user documentation is most useful when it is captured fast, found in seconds, trained against, and maintained on a review cadence. The features map to that assumption directly.
Capture happens through three mechanisms inside Whale. Video-to-SOP turns a screen recording of an end-to-end transaction walkthrough into a structured first-draft SOP automatically. Step Recorder captures a transaction or Fiori app workflow as a step-by-step guide with screenshots, which is the fastest way to document a daily process like creating a sales order in VA01 or posting a vendor invoice in FB60. The Video Screen Recorder handles longer walkthroughs with narration.
Findability is the job of Alice, the integrated AI assistant. When an AR clerk types “how do I post a credit memo with a different payment term?”, Alice answers from the client’s own documented processes. That single capability is the difference between adoption and a phone call to the consultant.
Training is wired in through Training Flows, which sequence SOPs into role-based learning paths for new joiners, and AI-Generated Quizzes, which confirm comprehension. A new buyer onboarded six months after go-live moves through a structured path covering the specific Material Master transactions, vendor evaluation flow, and purchase order release strategy used at this client, rather than generic SAP training.
Maintenance happens through Expert Review Intervals, which flag SOPs that are due a check, and Version History, which tracks changes over time. The mechanism keeps documentation alive after the consultant rolls off. When the client extends a custom field on the Material Master in month nine, the SOP for material creation can be flagged for an owner to review and update.
The clean way to position Whale on an SAP engagement is as the end-user documentation layer that sits alongside Solution Manager. Solution Manager holds the technical record. Whale holds what the end users need to do their daily work. The two systems serve different audiences and do different jobs.
Five practical use cases for Whale in an SAP engagement
The same five jobs come up on almost every SAP implementation, regardless of the modules in scope.
Transaction runbooks. End users need a clear walkthrough of the daily transactions they will run. Posting an invoice in FB60. Creating a purchase order in ME21N. Creating a sales order in VA01. Running the goods receipt in MIGO. Capture these in Step Recorder during the build or training phase, in the exact configuration the client will use, and the end-user team has a reference they can find in seconds when memory fails.
Master data maintenance procedures. Creating a new vendor in BP, extending a material to a new plant, opening a new GL account, adding a customer to a new sales area. These are the procedures that get done rarely enough to be forgotten between instances and frequently enough to matter. Documenting them in Whale with assigned owners and review intervals removes the “ask the consultant” reflex.
Business Process Owner playbooks. Each BPO ends up responsible for a slice of the implementation: AR for the AR BPO, procurement for the MM BPO, payroll for the HR BPO. A BPO playbook in Whale documents the daily routine, the exception handling, the month-end and year-end activities, and the decisions the BPO is empowered to make without consultant involvement. The BPO becomes self-sufficient faster, which is what the client paid for.
Role-based onboarding paths. Every six to twelve months, the client hires someone new into a role the implementation touched. Without a structured onboarding path, the new hire learns by interrupting senior team members. With Whale’s Training Flows, the new AR clerk moves through a defined sequence of SOPs and quizzes that cover exactly the work they will do. Onboarding turns from a six-month osmosis into a thirty-day path.
Change request triage. Many change requests that arrive in month nine are documentation gaps in disguise. A user does not know how to do something, the request escalates to “we need a custom report” when the real answer is “we need an SOP for the existing report”. A well-maintained Whale workspace catches these requests at the documentation layer and saves the client and the consultant the cost of unnecessary custom development.
How to introduce Whale into an SAP engagement
Three practical moments work best for a smaller specialist consultancy.
The first is during the blueprint or design phase. Capture the existing client processes in Step Recorder before the build starts. The artifacts serve as discovery outputs and as the baseline against which the new state will be documented.
The second is during the build and unit-testing phase. As transactions are configured and tested, Video-to-SOP captures the new-state walkthrough in real time. The consultant builds and documents in the same motion. Documentation captured during the build sticks; documentation deferred to “after go-live” rarely happens.
The third is during the first weeks after go-live. This is when adoption either takes hold or fails. Assign training flows to end users in their first week on the new system, capture FAQ answers in Whale as they come up on support calls, and let Alice handle the second wave of questions that would otherwise become consultant phone calls.
The Whale Partner Program for SAP consultants
Every SAP implementation consultant recommends tools to clients during engagements. Most of those recommendations are uncompensated. The Whale Partner Program is built to change that for the end-user documentation recommendation specifically.
Three tiers paying recurring lifetime commission for as long as the referred client stays on Whale.
Associate pays 10% recurring lifetime commission, includes access to Whale Academy, and assigns a dedicated Partner Manager. The entry tier for consultants starting to recommend Whale.
Premium pays 20% recurring lifetime commission, opens eligibility for certification, lists the consultant in the Whale Partner Directory, and unlocks premium co-marketing. The tier for consultants building a meaningful Whale practice alongside SAP work.
Leader pays 25% recurring lifetime commission, opens advanced professional service opportunities, and provides a featured Leader directory listing.
For a freelance SAP consultant running two or three module implementations a year, the recurring commission on each engagement compounds across years. The recommendation was going to happen anyway. The partner program turns it into a revenue line that supports the consultant well beyond rolloff.
How to get started
Two steps.
First, open a free Whale workspace and document one transaction or master data procedure from a current engagement. The capture experience, findability through Alice, and assignment workflow become clear within an hour.
Second, apply to the Whale Partner Program. The application takes about 60 seconds, and a dedicated Partner Manager handles enablement from there.
An SAP implementation lives or dies on adoption. Adoption lives or dies on end-user documentation. End-user documentation lives or dies on whether the team can find it, train against it, and keep it alive after the consultant rolls off. With the right layer in place, the calls in month four taper off, the client team operates the system confidently, and the engagement compounds into the next referral.
