*Gap samples / Gap 13 - Internal playbook (docs, product, support)*

# Update the docs when a feature ships: internal runbook

An internal process guide, the kind the help center never shows customers. You finish it with every page that mentions a changed feature updated, a release note published, and support told what changed, in the same week the feature ships. It matters more at EULER than at most companies, because EULER's AI assistants read the help center too.

**Gap:** 13 of 13 · **Reader:** Technical writer, product manager, support lead · **Type:** Internal runbook

## Why this page needs to exist

Several help center pages describe EULER as it was, not as it is. The Change Log's newest entry is 19 March 2026. The API & Webhooks collection documents the workflow API while the API Reference documents API v1. DealFlow AI shipped with no article. None of these is a writing problem. Each is a missing step between "the feature shipped" and "the docs changed".

The cost is higher than a stale page. The EULER MCP connector includes a help tool that searches the public help center and returns article text to Claude, ChatGPT and other assistants. A stale article is now also a stale answer, delivered with confidence inside a customer's AI chat.

---

*Sample documentation starts here*

## When to run it

- A feature ships, changes behavior, or is renamed.
- An API field, endpoint or error is added, changed or deprecated.
- Support answers the same "how do I" question three times in a week. **[CONFIRM THRESHOLD WITH SUPPORT]**

## What can go wrong

- Updating the main article and missing the other pages that mention the feature: MCP prompt guides, Slack guides, Forms 2.0, the API Reference.
- Publishing before the feature reaches every account. Beta features, such as API access, need the beta stated on the page.
- Leaving the Change Log for later. Later is how it stopped in March.

## Steps

1. **Get the change in writing before release**

   From the engineer or PM, get: what changed, who it affects, whether anyone must act, and the release date. Ask as statements to confirm: "Starting [date], `referral_type` is optional. Yes / no / correct me."

   **Check:** you can write the release note's "Affects" and "Action required" lines without guessing.
2. **Find every page that mentions the feature**

   Search the help center for the feature name and its old name, then the API Reference and the MCP connector reference. Search the MCP prompt guides too: they often describe behavior in passing.

   **Check:** a written list of pages, each marked update, unchanged, or retire.
3. **Update the pages, and test what they describe**

   Run every changed procedure in a test workspace. Every step **shall** keep its Check line, and the check **shall** still be true.

   **Check:** each page's updated date is this week, and you ran each procedure once.
4. **Publish the release note the same day**

   Use the format in [Release notes](12-releasenotes.md): title in the reader's words, who it affects, action required first.

   **Check:** the Change Log's newest entry is this release.
5. **Tell support and customer success**

   Post one message in the team channel: what changed, the links to the updated pages, and the question customers are likely to ask. Support **should** answer with a link, not a rewritten explanation.

   **Check:** support can find the change from the links alone.
6. **Ask the assistants**

   Through EULER MCP or PAM, ask the question a customer would ask about the feature. The answer should match the updated page.

   **Check:** the assistant cites the updated article and repeats its current behavior. If it does not, find out when the help search index refreshes. **[CONFIRM INDEX REFRESH]**

## Quarterly review

Once a quarter, sort the help center by updated date and review every page older than six months. **[CONFIRM INTERVAL]** Each one gets one of three outcomes: still true, updated, or retired with a redirect.

## What wrong looks like

**WRONG - RELEASE CHECKLIST**

```
[x] API v1 live
[x] API Reference published
[ ] Help center
[ ] Change Log

Why it fails: the reference is right and the help center
is not, so a developer who starts in the help center
follows the older API. A release is not done until
every page that mentions it is done.
```

## Confirm with engineering and product

1. Releases are announced internally in [channel], [days] before they ship. Correct me.
2. The MCP help tool searches the live help center, or an index refreshed every [interval]. Correct me.
3. The technical writer owns the Change Log. Yes / no / correct me.
4. Beta features are listed at [place], so docs can say which accounts have them. Correct me.

### Related documentation

- [Change Log](https://support.eulerapp.com/en/a/change-log)
- [Connecting EULER MCP to Your AI Assistant](https://support.eulerapp.com/en/c/euler-mcp-customers/getting-started), where the help tool is part of the connector
- [EULER MCP connector reference](https://mcp.eulerapp.com/public/docs) and [API Reference](https://api.eulerapp.com/docs)
- [PAM AI Knowledge Sources](https://support.eulerapp.com/en/c/ai-agents/pam-ai-knowledge-sources), the customer-side version of the same problem
- [Docs as Code (Write the Docs)](https://www.writethedocs.org/guide/docs-as-code/), for tying doc updates to the release process

### Sources for this page

- MCP connector reference: euler\_help (searches the public help center, returns article text and a citable URL).
- Change Log (newest entry 19 Mar 2026). API Reference (API access in beta). Help center Authentication article (workflow API).
- EULER Technical Writer job post: "Publishing documentation once and letting it go stale" listed under what will not work.

### Next

- Gap 11: [Release notes](12-releasenotes.md). The format step 4 uses.
- Gap 12: [Style guide](13-styleguide.md). The checks step 3 applies.

---

*Independent writing sample by Bachtiar Widyantoro (bachwidy.site), November 2026. Not published or endorsed by EULER. Free to reuse and edit. Customer names in examples are fictional. Anything marked [VALIDATE ...] or [CONFIRM ...] is not settled by a public source and needs checking before publishing.*
