Process Discovery for SaaS Implementations (2026 Playbook)

Process discovery is the phase of a SaaS implementation where you document how the customer's work actually happens today, step by step, role by role, system by system, before you configure anything. Done well it takes one to three weeks of elapsed time and two to six working sessions, produces a current-state (as-is) process map plus a fit-gap list, and it is the cheapest place in the whole project to find the surprises that otherwise arrive as change requests in week nine. Skip it, or run it as a product demo with questions bolted on, and you end up configuring against the process the customer wishes they had.

This playbook covers what to capture, who to interview, which questions expose the real process instead of the official one, how long discovery should take at each deal size, and how to turn the map into configuration decisions the customer signs off on. It is written for implementation managers and forward-deployed engineers who have to learn a customer's business before they can build for it.

What is process discovery in a SaaS implementation?

Process discovery is requirements gathering focused on workflow rather than features. You establish where a process starts and ends, who touches it, which systems it passes through, what decisions get made along the way, and what happens when something goes wrong. The output is an as-is process map. SAP Signavio's process discovery guide is explicit that a useful as-is map shows the steps people actually follow, including manual workarounds and repeated checks, and that you should involve the people who do the work rather than only the managers who describe it.

It sits between the sales handoff and configuration. Sales discovery answers "should they buy"; implementation discovery answers "how exactly does this work here, and what does the product need to do about it." They are different documents at different levels of detail, which is why the sales-to-onboarding handoff rarely contains what you need.

Three terms you will run into:

• As-is map: how the process runs today, including exceptions and workarounds.
• To-be map: how it should run once your product is live. Keep it separate; mixing the two during discovery is the fastest way to end up with an idealized map.
• SIPOC: a one-page summary of Suppliers, Inputs, Process, Outputs and Customers. ASQ positions it as the first artifact, built before any flowchart, with the process block limited to the five to seven core activities.

If you need a shared vocabulary for naming processes across customers, APQC's Process Classification Framework organizes business work into 13 top-level categories that break down into process groups, processes, activities and tasks. You will map far less deeply than that. Still, naming processes the way the framework does (order-to-cash, procure-to-pay, hire-to-retire) helps when you compare the same workflow across a dozen accounts.

Why does skipping discovery cost so much?

Because the errors it prevents are the expensive kind: the ones found after configuration, after data migration, sometimes after go-live. PMI's Pulse of the Profession research found that 47% of unsuccessful projects fail to meet their goals because of inaccurate requirements management. Panorama Consulting's 2026 ERP Report found that more than a quarter of organizations exceeded their project budget, with additional technology needs the leading cause. Panorama's explanation is that organizations discover fatal misfits late in the project and then reach for scope expansion, custom builds and extra tools to close the gap.

The reason customers cannot simply hand you a process document is that they usually do not have one. In Lucid's 2025 survey of roughly 2,200 knowledge workers, only 16% said their workflows are extremely well documented, 71% said undocumented or ad-hoc processes affect their efficiency at least sometimes (22% said often or always), and only 4% said none of their team's workflows depend on knowledge that lives in one person's head. Operations was the function most dependent on person-bound knowledge (46%), followed by customer support (36%), which are exactly the teams most B2B SaaS products are sold into.

The same survey explains why the documentation never gets written: 41% cite lack of time, 30% lack of tools and 27% no clear owner. Nobody at the customer is going to fix this before kickoff. Discovery is you fixing it for them, for the slice of their operation your product touches.

Quality management has a name for the part of a process that is missing from the official version: the hidden factory. Armand Feigenbaum estimated it at 20% to 40% of an organization's total capacity, all the rework, side checks and workarounds that never appear in the documented flow. In a SaaS implementation the hidden factory is the spreadsheet the ops lead keeps "just to double-check," the approval that happens over DM, and the three-step exception that handles 15% of volume. Configure without finding those and the customer will rebuild them around your product, usually in the second week after go-live.

How long should process discovery take?

Long enough to see every core path and the top exceptions, and no longer. Discovery that runs open-ended turns into a reengineering project nobody is paying you for. Time-box it by deal size and put the end date in the project plan:

A rule of thumb we use: discovery should consume roughly 10% to 15% of the total implementation calendar. On a 90-day onboarding that is 9 to 14 days, which matches the mid-market row above. If your average onboarding runs longer than 90 days, discovery usually stretches with it, but it should never be the phase that stretches the most.

Two scheduling rules that save weeks. First, book every discovery session before the kickoff meeting ends; sessions scheduled "next week when calendars free up" are where two-week slips are born. Second, put the customer's process owners on the invite, not only the project sponsor. The people who do the work are the ones with the exceptions in their heads.

Who should you interview during discovery?

The people who execute the process, the people who approve it, and the people who own the systems it runs through. Most discovery fails by interviewing only the first name on the contract.

• Doers: the coordinator, analyst, rep or agent who runs the process daily. They know the exceptions, the workarounds and the actual cycle times. Two doers per process is the minimum; one gives you a person, and you need a process.
• Approvers and escalation points: whoever a stuck case goes to. Their rules are rarely written down, and they define your permission model.
• System owners: the admin of the CRM, ERP or ticketing tool the process touches. In Zylo's 2026 SaaS Management Index, business units now control 81% of SaaS spend while IT directly manages 15%, so the tool a process depends on is often owned by a team lead rather than central IT. Ask the doers what they open on screen, not just the IT contact.
• Downstream consumers: finance, reporting, compliance, whoever receives the process output. They tell you what "done" has to contain.
• The sponsor: last, for goals, constraints and the to-be direction. Sponsors describe the intended process; doers describe the real one.

Your stakeholder map from kickoff should already name most of these people. If it only lists the champion and an executive sponsor, discovery is where you fill it in.

Format matters too. A study of 24 practitioners at 12 software companies found that group techniques such as workshops and facilitated meetings were the most used elicitation method, with requirements instability (needs and priorities changing mid-project) the predominant challenge. Workshops are efficient, but they let the loudest person in the room define the process. Pair each workshop with at least one short one-on-one with a doer who stayed quiet.

What should an as-is process map capture?

Enough that a colleague who was not in the room could configure from it. For every process in scope, capture these twelve fields. The first six are the SIPOC; the rest are where implementations go wrong.

Draw it as a swimlane: one lane per role, steps left to right, systems noted under each step. Swimlanes make handoffs visible, and handoffs are where most delays live. If you want a standard notation, BPMN 2.0 is the common one, but a whiteboard photo with clear lanes delivered the same day beats a perfect diagram delivered two weeks late.

Which questions reveal the real process instead of the official one?

Questions anchored to a specific recent case. Abstract questions ("how do you handle refunds?") return the policy; concrete questions ("walk me through the last refund you processed") return the process. People are unreliable narrators of their own routines, and the gap between described and observed behavior is as real for an ops team as it is for consumers in a survey.

A discovery script that works across products:

1. "Pick one from last week and walk me through it, start to finish." Do not interrupt on the first pass. Note every noun (documents, systems, people) for follow-up.
2. "Where did that one sit waiting, and for whom?" Surfaces handoffs and queue time.
3. "What did you open on your screen to do that step?" Surfaces systems and spreadsheets, including the ones IT has never heard of.
4. "What happens when the input is wrong or missing?" Surfaces exceptions and the person who handles them.
5. "Who would you message if this got stuck?" Surfaces the real escalation path and unofficial approvers.
6. "How often does that happen?" Turns anecdotes into volumes so you can prioritize.
7. "Is there a check you do that isn't in the procedure?" Surfaces the hidden factory directly.
8. "What would break if we removed this step?" Separates controls from habits.
9. "Who else does this differently?" Surfaces variants across teams and regions before they surface in UAT.
10. "What do you send onward, and to whom?" Confirms outputs and downstream requirements.

Where you can, add observation: twenty minutes watching someone run the process over a screen share exposes more than an hour of description. Process mining tools exist for the same reason at enterprise scale. Gartner's 2025 Magic Quadrant notes that process mining spend grew more than 30% in 2024, driven by organizations that could not automate or optimize what they did not understand. You do not need a mining platform for a 90-day onboarding. You need the screen share.

How do you run a discovery session?

Ninety minutes, one process, one recent case, one map on the screen by the end. A repeatable agenda:

1. Scope (5 min): state the process, its start and end points, and what is out of scope today.
2. Walkthrough (30 min): a doer narrates a real recent case while you build the swimlane live. Sharing your screen while you draw keeps the room honest; people correct a diagram faster than they correct a sentence.
3. Exceptions and variants (20 min): run the questions above. Add branches to the map as they come up.
4. Systems and data (15 min): for each step, confirm the system, the fields and who owns the record. Feed this straight into your onboarding questionnaire or data request rather than asking twice.
5. Parking lot (10 min): to-be ideas and feature requests go here, visibly, so they are heard without contaminating the as-is map.
6. Confirm (10 min): read back the steps, decisions and exceptions. Name the owner who will validate the written map within two business days.

Record every session and keep the transcript with the project. Discovery produces dozens of small commitments ("we'll get you the approval matrix," "finance needs the export monthly") that are easy to lose between the call and the plan. Stipulate is built for exactly this: it reads call transcripts and the customer's Slack channel and builds a record of requirements, decisions, stakeholders and processes, each linked to the message or transcript line it came from, so discovery findings become tracked items instead of notes scattered across five docs. Whatever tool you use, the rule is the same: nothing said in discovery should exist only in one person's memory. AI meeting notes handle the capture; you still own the confirmation step.

Send the written map within 48 hours while the session is fresh. Ask for corrections rather than approval; people mark up a draft more readily than they sign a clean one.

How do you turn the as-is map into configuration decisions?

Through a fit-gap analysis: one row per process step, classified by how your product handles it. This is the document that prevents both scope creep and the silent workaround.

The gap rows are the whole reason discovery exists. Every one that is not decided in writing before configuration becomes a change request later, which is the pattern Panorama describes as fatal misfits discovered late. If a gap forces a scope conversation, have it now, through the change control process you set up at kickoff.

Three more things to produce from the map before you configure:

• A decision log: every "we'll do it this way" from discovery, with the person who said it. Champions change, and when a champion leaves, the log is what keeps the configuration defensible.
• UAT scenarios: each exception and each pain point becomes a test case. If discovery found nine exceptions, UAT has at least nine scenarios beyond the happy path.
• A customer deliverables list: approval matrices, field lists, sample files, sandbox access. Discovery generates most of the items you will later chase during onboarding, so capture them with owners and dates on the spot.

How is discovery different for forward-deployed engineers?

Deeper, and it never fully ends. A forward-deployed or solutions engineer is building something inside the customer's operation, so the as-is map is more than input to configuration; it is the specification. Three adjustments:

• Map data as well as steps. For each step record the entities, fields, identifiers and where the source of truth lives. Integration surprises come from identifiers that do not match across systems.
• Prototype inside discovery. Showing a rough build of one step in session three tells you more than two more interviews would. Customers describe processes more precisely when reacting to something concrete.
• Keep the map live. Requirements will move; the elicitation study above found instability the top challenge. Version the map, date each change and tie it to the decision log so the build history is explainable after the customer's team turns over.

If you are still deciding whether your implementations need this depth at all, this guide to when to hire forward-deployed engineers covers the signals.

What are the most common discovery mistakes?

• Mapping the intended process. Interviewing only the sponsor and the champion produces the policy manual with boxes around it. Always include doers and always anchor to a real case.
• Running discovery as a demo. Showing the product first makes the customer describe their process in your product's vocabulary, and the parts your product does not model quietly drop out of the conversation.
• Ignoring the happy path's neighbors. A map with no exception branches is unfinished. Ask for the volume of exceptions; if it is over 10%, they need their own lane.
• Letting to-be leak into as-is. Use the parking lot. Redesign is a separate conversation with the sponsor, after the current state is confirmed.
• Skipping confirmation. An unvalidated map is a guess. Get a named owner to approve each process map in writing before configuration starts.
• Losing the record. Notes in five people's docs, decisions in DMs. Keep one source of truth linked to the transcript, and reuse it at the CSM handoff.
• Discovery without an end date. Time-box it, publish the date at kickoff, and treat "we found another process" as a scope decision rather than a schedule extension.

Next steps: a process discovery checklist

1. At kickoff, list the processes in scope and book every discovery session before the meeting ends. Set the discovery end date.
2. For each process, identify two doers, one approver, one system owner and one downstream consumer.
3. Run a 90-minute session per process using one real recent case; build the swimlane live and record the call.
4. Capture all twelve fields, with exceptions and workarounds as first-class branches.
5. Send the written map within 48 hours; get a named owner's confirmation within two business days.
6. Produce the fit-gap table, the decision log, the UAT scenario list and the customer deliverables list from the map.
7. Take every gap through change control before configuration begins.
8. Store transcripts, maps and decisions in one place the whole delivery team can search; the same record feeds status updates, UAT and the handoff to CS.

Discovery is the least glamorous phase of an implementation and the one with the highest return per hour. Two weeks spent finding the hidden factory is cheaper than the change request that finds it for you.