How to build post-decision process documentation
When a buyer asks an AI model “what happens after I choose this provider?” and your implementation process is undocumented, the model has nothing to cite. Document it and you win the decision stage by default.
Executive summary
Most providers treat implementation as an internal process. Buyers treat it as a decision criterion. In the US CRM market, HubSpot project data shows the Final Verification stage (D06) has a Stage Health of 6 out of 100 with seven hesitation signals blocking commitment. Every one of those signals asks for process information: data migration steps, rollback plans, SLA guarantees, escalation timelines, total cost of ownership over three years.
The Internal Alignment stage (D05) scores 13 out of 100, with concerns about learning curves, hidden fees, and integration complexity stalling internal approval. These buyers are not evaluating your product anymore. They have decided. What stops them is the absence of documented process.
This playbook covers the six page types within process documentation, how to extract the content from your Seedli CDJ data, and a worked example that maps D06 buyer questions to published pages.
When to produce this content
Post-decision process documentation is the right investment when three conditions are present. All three should be visible in your Seedli data before you commit to producing the content cluster.
Signal 1: D06 buyer questions ask about process, not product
Open CDJ → D06 Final Verification. Read the buyer questions. If more than half of them are about implementation (migration steps, timelines, training, support), the buyer has already decided on your product and is now evaluating whether the transition is safe. These questions are your table of contents. Each question is a page you should publish.
Signal 2: Elimination triggers name process complexity
Open Consideration → Providers and read your provider type’s elimination triggers. If they include phrases like “longer implementation times,” “significant change management required,” or “perceived as overly complex,” these are not product objections. They are process fears. Process documentation that answers these fears with specifics (weeks, phases, named roles) converts them from elimination triggers into progression signals.
Signal 3: An implementation partner exists as a separate provider type
If your Seedli providers screen shows an implementation or consulting partner as its own type, your market has created an entire category to handle the complexity your product introduces. That is a signal that process documentation is not optional. It also means buyers who cannot afford a separate implementation partner need your documentation to fill the gap. A provider that publishes its own process captures the same trust that implementation partners earn.
With the signals confirmed, here are the screens that supply the content.
The Seedli screens to open
Process documentation draws from four screens across two Seedli modules. The CDJ module supplies the buyer questions and hesitation signals. The Consideration module supplies the structural context that explains why those questions exist.
CDJ → D06 Final Verification
What to extract: All buyer questions, progression signals, and hesitation signals. The buyer questions become your content outline: each question is either a standalone page or a section within a larger guide. The hesitation signals tell you the emotional framing behind each question (a stakeholder raising user adoption concerns, legal counsel asking about data residency, IT flagging integration vulnerabilities). The progression signals show you what “done” looks like for each topic: when the legal team approves the MSA, when the implementation kickoff is scheduled.
Why it matters: D06 is the last stage before commitment. A Stage Health of 6/100 means almost every buyer stalls here. The questions they ask at this stage are the exact questions your process documentation should answer. You are not guessing at a content strategy. You are reading the buyer’s final checklist.
CDJ → D05 Internal Alignment
What to extract: Buyer questions about internal readiness (who owns the implementation, what the rollout milestones look like, what the typical timeline is for a company of their size) and hesitation signals about internal resistance (learning curve concerns, scalability doubts, hidden fee worries, the customization versus out-of-the-box debate).
Why it matters: D05 is where the decision-maker has said yes but the organisation has not. The CTO wants a security architecture review. The VP Sales wants a follow-up meeting with IT and Sales Ops. The Revenue Operations Lead is drafting an internal migration plan. Your process documentation serves these internal stakeholders directly: each of them needs a different slice of the same implementation story.
Consideration → Providers (your type detail)
What to extract: Elimination triggers that reference process complexity (longer implementation, change management, overly complex features). Outbound switching flows where the trigger is speed or complexity (buyers leaving your type for a simpler alternative because your implementation was too heavy). The existence of an Implementation Partner as a separate provider type.
Why it matters: Elimination triggers about process are objections you can answer with documentation. “Longer implementation times” becomes “implementation takes 8 to 12 weeks in four phases.” The vague fear is replaced by a specific timeline. If buyers are switching to simpler alternatives because they cannot see your process, you are losing them to a documentation gap, not a product gap.
Consideration → Tradeoffs → Criterion Intelligence
What to extract: The Content Strategy Matrix quadrant for Flexibility & Customization (or whichever criterion covers implementation-phase decisions in your market). Look for Battle Zone or Hidden Differentiator criteria whose buyer language describes configuration, setup, or integration questions.
Why it matters: A criterion like Flexibility & Customization is often treated as a product feature. In practice, the buyer language reveals it is an implementation question: “Can we configure dashboards without developer help?” and “How easy is it to add custom fields?” are not product evaluation questions. They are onboarding questions. If the criterion is Battle Zone (high importance, high tension), process documentation that answers these questions with specifics resolves the market confusion that the quadrant describes.
The data tells you what buyers need to know. Here are the six page types that deliver it.
The six page types
Post-decision process documentation is not a single page. It is a content cluster of six page types, each mapped to a category of D06 buyer question. Produce them individually: one page per topic, each independently citable. A single monolithic “implementation overview” forces the AI model to extract the relevant section. Six dedicated pages let the model match each page to the specific question.
D06: "What's the typical implementation timeline for a company our size?"
A phased timeline with named stages, durations in weeks, and the activities in each phase. Include company-size brackets if timelines vary (50-user company vs 500-user company). Name the roles involved at each phase: who from the buyer's team is needed, when, and for how long. This is the page buyers share with their CFO to justify the project plan.
D06: "Can you walk us through the exact steps for data migration and the rollback plan?"
Step-by-step migration process from the most common source systems. Include data mapping, validation checkpoints, parallel running period, and the specific rollback procedure if something fails. The rollback plan is not optional: D06 buyers ask for it because they fear irreversibility. Document exactly what happens if the migration needs to be reversed at any checkpoint.
D05: "Concerns about the learning curve for the sales team during transition"
The training programme by role: what the CRM administrator learns in week one, what the sales team learns in week two, what the marketing team learns in week three. Include time commitments (hours per person), delivery format (live, on-demand, documentation), and how you measure proficiency. Address the learning curve fear directly: name the median time-to-proficiency from previous implementations.
D06: "Can you provide references from companies who have integrated with our key existing tech stack?"
Published documentation for the most common integration patterns: marketing automation, ERP, customer support, analytics. For each integration, show the connection method (native, API, middleware), data flow direction, sync frequency, and known limitations. This page is for the CTO and the IT team. It answers the D05 hesitation signal about the CTO requesting a technical architecture overview.
D06: "What is the exact process for escalating critical support issues and resolution times?"
Your support tiers, response time commitments by severity, escalation paths, and named communication channels. Include the SLA penalties if applicable. Address the D06 question about guaranteed uptime and what happens when the guarantee is not met. This is the page legal teams review before signing the contract.
Tradeoffs: Flexibility & Customization buyer language
What can be configured without developer help (dashboards, reports, workflows), what requires technical customization (custom objects, API integrations, advanced automation), and what the boundaries are. Address the D05 debate between customization and out-of-the-box functionality directly: show where the line is and what it takes to cross it.
The structure defines what to publish. Here is how to write it so both buyers and AI models can use it.
How to write each page
Process documentation fails when it is written like marketing copy. The buyer reading this content has already decided on your product. They are not evaluating features. They are evaluating whether the transition is manageable. The writing needs to match that mindset.
Use specific numbers, not ranges
“Implementation typically takes 8 to 12 weeks for a company of 100 to 250 users, with a dedicated project manager assigned in week one.” Not “we offer fast implementation.” The D06 buyer is building an internal business case. They need numbers they can put in a project plan and present to their finance team. Every number you leave out is a number they have to guess, and guessing creates hesitation.
Name the roles, not the teams
“Your CRM Administrator will work with our Implementation Consultant during weeks 2 through 4 to configure pipeline stages, permission sets, and reporting dashboards.” Not “our team works closely with your team.” The D05 buyer questions ask explicitly who will own the implementation internally. Your documentation should answer with the same specificity: which role on their side, which role on your side, what they do together, and when.
Include the rollback at every checkpoint
The D06 buyer question about rollback plans appears in every market where implementation is complex. Buyers fear irreversibility. For each phase of your implementation timeline, document what happens if the buyer needs to stop or reverse. At the end of data mapping: “if validation reveals data quality issues, we pause migration and remediate before proceeding. Your existing system remains active throughout.” The rollback plan is not a section at the end. It is a note at every transition point.
Segment by internal audience
The same process documentation serves multiple internal stakeholders. The CTO needs the integration architecture and security review. The VP Sales needs the training timeline and productivity impact. The CFO needs the total cost of ownership and the milestone-based payment schedule. The CRM Administrator needs the configuration guide and admin training. Either produce separate pages for each audience or structure a single page with clearly labelled sections that each stakeholder can navigate to directly. Use heading hierarchy to make each section independently extractable.
Do not hide the hard parts
If data migration takes two weeks of parallel running where both systems are active, say that. If the sales team loses 15% of productive hours in week three during training, say that. Process documentation that only describes the ideal path loses credibility the moment the buyer talks to a reference customer who experienced the messy parts. Name the common friction points and explain how you handle them. This is the same honesty principle that drives elimination defence content: naming the concern before the buyer raises it converts a fear into a managed expectation.
With the writing principles clear, here is how they apply to a real market with real data.
Worked example: US CRM market
We set up a Seedli project for the US CRM platform market with HubSpot tracked as a Full-Suite CRM Platform. The market contains seven provider types: three Primary (Vertical CRM Specialist, Sales-Focused CRM Vendor, Full-Suite CRM Platform), three Secondary (CRM ISV and App Marketplace Partner, CRM Implementation and Consulting Partner, CRM Data and Intelligence Provider), and one Fallback (Non-Standard Provider). Here is how the CDJ data maps to a process documentation cluster.
The D06 problem: Stage Health 6/100
Final Verification in this market has eight buyer questions and seven hesitation signals. The stage health score of 6 out of 100 means nearly every buyer stalls here. The eight questions read like a documentation audit:
Every question maps to a publishable page. The buyer is not asking these questions out of curiosity. They are assembling an internal business case. Each answer they cannot find on your site is a delay in the decision.
The D05 problem: internal stakeholders blocking
Internal Alignment scores 13/100, with six hesitation signals. These are not buyer objections. They are organisational fears:
Each of these maps to a section within your process documentation. The learning curve concern maps to the onboarding and training plan. The security question maps to the integration architecture page. The hidden fee worry maps to the TCO breakdown. The customization debate maps to the configuration guide. Your process documentation does not just serve the decision-maker. It serves the internal coalition that has to agree before the contract is signed.
The elimination triggers that process documentation neutralises
The Full-Suite CRM Platform has eight elimination triggers. Three are directly about process:
“Longer implementation times”
Publish the implementation timeline page with phase durations by company size. Replace "longer" (a relative judgement) with "8 to 12 weeks in four phases" (a specific plan).
“Significant change management required for adoption”
Publish the onboarding and training plan with role-by-role training schedules and time-to-proficiency benchmarks. Replace "significant change" (a fear) with "12 hours of training over three weeks, with 85% of users self-sufficient by week four" (a managed expectation).
“Perceived as overly complex for specific departmental needs”
Publish the customization guide that shows what is configurable without developers and where the complexity boundary sits. Replace "overly complex" (a perception) with "the sales team uses five core screens; advanced automation is optional and configured by admins" (a scoped description).
The remaining five elimination triggers (higher cost, too much functionality, existing tools adequate, high implementation cost, complex features) are partially addressed by the TCO breakdown and configuration guide. The pattern is the same: vague fears become specific, answerable descriptions.
The switching signal: net -3 outbound
The Full-Suite CRM Platform has the worst net switching flow in the market: four inbound, seven outbound (net -3, escalation index 33%). Buyers arrive from Sales-Focused CRM Vendors (seeking complexity, governance, and scale) and from Vertical CRM Specialists (seeking scale). But they leave for five different destinations: back to Sales-Focused (cost), to CRM ISV Partners (cost, risk), to Data and Intelligence Providers (governance, risk), to Vertical Specialists (complexity), and to Implementation Partners (speed).
Two of those outbound triggers (complexity and speed) are directly about the post-decision experience. A buyer who leaves a Full-Suite platform for a Vertical Specialist because of “complexity” is a buyer who could not see a path through the implementation. Process documentation does not remove the complexity, but it makes the complexity navigable. A buyer who switches to an Implementation Partner because of “speed” is a buyer who needed a faster path to go-live. A published timeline with phase-skipping options for simpler deployments could intercept that switch.
The implementation partner signal
The CRM Implementation and Consulting Partner exists as its own provider type in this market: Secondary classification, highest importance score of all seven types (2.65/3), highest positive market positioning (+0.25 vs market), and the most telling statistic: one inbound switching flow, zero outbound. Buyers come to implementation partners and do not leave.
The description defines its function: “CRM configuration, data migration, customization, and go-live delivery.” This is exactly the content cluster described in this playbook. The market has created a separate provider type to handle the documentation and delivery that the platform vendor leaves unpublished. A Full-Suite CRM Platform that documents its own implementation process captures some of the authority that currently flows to implementation partners by default.
The criterion that belongs in process documentation
Flexibility & Customization is a Battle Zone criterion in this market: SOS 0.26, Buyer Importance 2.42/3, Market Tension 0.45, Content Opportunity 13%. It ranks third in the Criterion Intelligence table by buyer importance. The buyer language reveals why it belongs in process documentation rather than product marketing: “Can we configure dashboards and reports without developer help?” “Can we tailor workflows to our unique sales process?” “How easy is it to add custom fields or objects?” “Is it scalable as our business grows?”
These are not questions a buyer asks during product evaluation. They are questions a buyer asks during implementation planning. The Full-Suite Platform scores 2.5 on this criterion (below the 3.0 it achieves on five others), which means the market sees room for improvement. Process documentation that shows exactly what is configurable, by whom, and how long it takes addresses the criterion gap with evidence rather than assertion.
With the worked example showing how CDJ data maps to content, here is how to publish for AI citation.
Schema and publishing strategy
Process documentation has publishing requirements that differ from other content types because it serves two audiences simultaneously: prospects at D06 who need confidence to commit, and existing clients who need operational reference material. The publishing strategy should make both audiences findable by AI models.
URL structure
Name the process in the URL. “/implementation/data-migration-guide” matches the buyer’s query. “/resources/getting-started” does not. Use a shared parent path (/implementation/ or /onboarding/) for the entire cluster so AI models can infer that these pages are related and the site has comprehensive process coverage.
Schema markup
HowTo schema for the implementation timeline and data migration guide (step-by-step processes with named steps and durations). FAQPage schema for pages that answer specific D06 questions. Article schema with datePublished and dateModified on all pages. Process documentation ages quickly: update dateModified every time a timeline, SLA, or escalation path changes.
Heading hierarchy
Follow the heading hierarchy technique. H2s should name the process phase or topic (“Phase 2: data migration and validation”). H3s should mirror the buyer’s question (“What happens if the migration needs to be rolled back?”). This lets AI models match a buyer’s question to the specific subsection that answers it, rather than citing the page as a whole.
Internal linking
Link the process documentation cluster to your migration and switching guide (which covers the before-you-switch narrative) and to your direct-answer content (which can host individual D06 questions as FAQ entries). The migration guide brings the buyer to the decision. The process documentation converts the decision into a commitment. The direct-answer pages let AI models cite individual answers without loading the full documentation.
Freshness
Process documentation has the highest freshness requirement of any content type in this playbook series. When your implementation timeline changes, the page is wrong. When your SLA terms update, the page is wrong. When you add a new integration, the architecture page is incomplete. Set a quarterly review cadence and update dateModified with every revision. Stale process documentation is worse than no documentation: it creates false expectations that erode trust at the exact moment the buyer is deciding to commit.
Best for
Decision-stage conversion and post-purchase retention. The prospect audience is buyers at D06 Final Verification who have decided on your product and are now evaluating whether the transition is safe. The existing-client audience is users who need operational reference material. The same content serves both, published once.
Action
Serve two CTAs from the same content. For prospects: a “schedule your implementation kickoff” CTA that moves them from Final Verification to signed contract. For existing clients: a customer portal link or support channel. Segment by login state if possible. If not, place both CTAs and let the reader self-select.
See the questions buyers ask before they commit
Seedli maps every buyer question and hesitation signal at Final Verification. Your process documentation starts with the exact checklist your buyers are working through.
Get startedThis is part of the Seedli playbook series on content types that shape AI visibility. See all playbooks and techniques.