# Google Docs to ebook — an original source-to-chapter example

**This is an invented editorial exercise, not a real customer book and not a Scribora-generated output.** All names, scenarios, dates and figures below are fictional. You may copy and adapt the framework to material you own. No Google Docs files or third-party content are included.

**Reader promise:** A practical guide for a solo design-studio owner to scope a client project without surprises.

## A. Three raw Google Docs (fictional excerpts)

The following material is deliberately messy, overlapping, and written for different purposes. It represents the text you might export from separate Google Docs as DOCX or Markdown, not a finished manuscript.

### Document A — "Kickoff questions" (author's private operations note)

_Last edited for the example: 2026-09-12._

- "Before I quote, ask: who signs off, what does success look like, and what materials can the client actually deliver by Friday?"
- "I forgot the approval question on the Morrow project. We made two sets of concepts because the buyer wasn't the approver."
- "Could use a better opening than five pages about why communication is important."
- "Maybe charge for discovery? Need to check the commercial process rather than invent a fee."

**Editorial label:** Core method; one fictional anecdote requiring anonymization if it were real. The incomplete pricing question is a gap, not an established recommendation.

### Document B — "Proposal v3" (author's template)

_Last edited for the example: 2026-10-05._

> Deliverables: one visual direction; three screen layouts; one documented review round. Changes beyond that scope require a separate estimate. The client supplies approved copy before the layout phase begins.

- The template does not say *who* can authorize changes.
- A reviewer wrote a comment in Google Docs: "What if legal wants another round?" The comment is useful editorial feedback, **not** a reliable source for a policy.
- Legal terms and enforceability vary. Any final contract needs appropriate professional review.

**Editorial label:** Supporting evidence for the "scope before price" chapter; not a ready-made contract for readers.

### Document C — "Retrospective: late files" (team debrief)

_Last edited for the example: 2026-10-19._

- Work paused when photographs arrived without permissions.
- The original timeline assumed all content was ready at kickoff; it wasn't.
- We should call readiness a *decision* with explicit pass/fail criteria.
- "Every project was late" is an emotional sentence from the meeting, not an analyzed statistic. **Do not reproduce as a factual claim.**

**Editorial label:** Supporting edge case, rights flag for photographs, and an evidence gap for any claim about how often this happens.

## B. Source-to-claim map

| Claim the book can make | Source | Status | Editorial action | Book destination |
| --- | --- | --- | --- | --- |
| Name the decision-maker before preparing a proposal. | A, observed practice | Author's advice; example unverified | Explain with a worked hypothetical; anonymize any real client | Chapter 1 |
| A useful proposal names deliverables and revision boundaries. | B, template | Direct text from an author-owned template | Explain how scope changes are authorized; keep legal warning | Chapter 2 |
| Content readiness can block the project timeline. | C, team note | Plausible internal example, not prevalence evidence | Use one bounded scenario; do not say "always" | Chapter 3 |
| Discovery must have a particular paid price. | A, open question | Unsupported | **Omit** until commercial evidence is supplied | No chapter |
| Every project runs late. | C, emotional statement | Unsupported generalization | **Remove**; do not turn into a statistic | No chapter |

## C. Reader-first outline, not the original file order

1. **Who can decide?** Confirm buyer, approver, and success criteria before quoting. (A)
2. **What exactly is being delivered?** Specify outputs, review boundary, and change process. (B, A)
3. **When can the work actually start?** Audit inputs, usage rights, and missing assets. (C, B)
4. **How to handle a change mid-project.** Give readers a decision tree and an annotated, original checklist. (B plus fresh author notes needed)

The fourth chapter cannot be produced faithfully from the three documents alone. The author needs to supply the missing decision tree; prose fluency does not fill that evidence gap.

## D. Before and after (human-written illustration)

**Before — document dump:**

> Who signs off? What does success look like? Need all client materials Friday. Deliverables: one visual direction and three screen layouts. Content can be late. Think about revision limits. Legal may want another round. This always happens.

**After — one short example passage for Chapter 1, written for this exercise:**

> Before you prepare a proposal, separate the person commissioning the work from the person authorized to approve it. They may be the same person, but guessing is expensive. Ask the client to name the final decision-maker, the outcome that will count as acceptance, and anyone who must review the work before sign-off.
>
> Imagine a studio that presents a design direction to a marketing manager, only to discover that a different stakeholder has final approval. The problem is not simply the extra meeting; it is that the project began without an agreed decision path. Write the approval path into the kickoff checklist before estimating the work. This illustration is hypothetical, not a report of a real client incident.

**Why the edit is different:** it combines a procedure from A with a clearly fictional example and removes unsupported claims from C. It does not invent legal advice, fee recommendations, or project statistics.

## E. Your own ten-minute source audit

Use this copyable table before uploading or pasting Google Docs material:

| Document | Reader job | Claim worth keeping | Owner / permission | Sensitive material | Contradiction or age | Chapter | Missing source |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |

**Practical route:** In Google Docs, use **File → Download** to export each relevant owned document as **DOCX** or **Markdown** where available. Inspect the downloaded text. Do not treat comments, suggestions, or collaborator identities as automatically publication-ready. In Scribora, bring the selected source files or notes into a project, inspect the resulting outline, and only then draft chapters.

**Sources for export behavior (checked November 4, 2026):**
- Google Docs Editors Help, [Create, view, or download a file](https://support.google.com/docs/answer/49114?hl=en).
- Google Docs Editors Help, [Use Markdown in Google Docs](https://support.google.com/docs/answer/12014036?hl=en).
- Google Drive Help, [Export your data](https://support.google.com/drive/answer/9759608?hl=en-ae) (a Google account archive is a separate operation from downloading one document).

*Use this as a worksheet, not as evidence that Scribora generated the demonstration prose.*