# Survey responses to ebook: a traceable editorial exercise

**Original teaching example, prepared November 7, 2026.** Everything in sections A–D is **fictional**: there was no survey, no real participant, no Scribora customer, no experimental study, and no AI-generated Scribora manuscript behind this example. The worksheet demonstrates an editorial method, not a conversion-rate or product-quality claim. The response sentences are invented for education and must not be marketed as field research.

This pack is also a small, reusable template for making a book from your *own* properly cleared survey material. Never upload an unredacted responses export or assume a response can be published merely because you collected it.

## A. The survey brief (fictional)

**Reader:** small design-studio owners trying to reduce handoff ambiguity.

**Proposed product:** a concise practical field guide, not an industry benchmark.

**Constructed question:** "What has made a recent client handoff difficult or easy?"

**Recruitment and sample:** none. Six invented sentences represent possible answer *types*. They support no numerical statement about real studios. All IDs here are fictional illustration labels, not pseudonyms for real people.

## B. Six invented raw answers and initial codes

| ID | Exact fictional answer | Theme code | Chapter destination | Caution |
| --- | --- | --- | --- | --- |
| F01 | We lost a week because nobody knew who approved the mockups. | Decision owner | 2 | An individual's account, not a measured average delay. |
| F02 | We began work before the client sent the brand files. | Missing assets | 1 | An example, not an estimate of frequency. |
| F03 | Requests came from several people after scope was agreed. | Change requests | 3 | Does not establish who was authorized. |
| F04 | The handoff worked because our one approver signed off early. | Successful exception | 2 | Contradicts a blanket story that every handoff fails. |
| F05 | Three stakeholders asked for different revisions. | Decision owner; change requests | 2 and 3 | Two themes in a single answer. |
| F06 | We never said which materials had to arrive before kickoff. | Missing assets | 1 | Describes one hypothetical omission. |

### How to count without misrepresenting the data

In the **fictional set only**, decision authority is relevant to F01, F04 and F05 (3/6, including a success case); asset readiness appears in F02 and F06 (2/6); and changes appear in F03 and F05 (2/6). These are **not mutually exclusive categories**. F05 appears twice. If this were a real convenience sample, these counts still would not establish population percentages; here they are only a check on the coding exercise.

Do not remove F04 to make the narrative more dramatic. It shows what worked and helps frame a useful action: name the approver before starting work.

## C. Claim-to-source ledger

| Candidate sentence | Kind | Evidence | Verdict | Safer handling |
| --- | --- | --- | --- | --- |
| "Most studios lose a week because nobody owns approvals." | Population claim | F01 only | REJECT | A single constructed account cannot support a prevalence claim. |
| "One example describes a week of delay when approval authority was unclear." | Observation of synthetic input | F01 | ALLOW IN EXERCISE ONLY | Say it is a fictional example; for real publication, verify the original, rights and scope. |
| "Early approval ownership can make handoffs smoother." | Proposed interpretation | F01 and countercase F04 | QUALIFY | Explain it as a possible mechanism, not a causal estimate. |
| "Set one decision owner before kickoff." | Author recommendation | No validated method from these answers | NEED AUTHOR INPUT | Explain when the recommendation applies and cite an independent method or actual expertise. |
| "Requests may need their own route and review." | Proposed interpretation | F03 and F05 | QUALIFY | Show the reader a defined review process supplied by the author. |
| "The six answers were collected from clients." | Provenance claim | None | REJECT | They were invented for this lesson. |

If you collect real data, keep the private respondent key outside the working manuscript. A claim ledger should preserve a safe source reference and the material limitations without including unnecessary personal details.

## D. Reader-first outline: three chapters, not three survey questions

**Chapter 1 — Is the project ready?** A checklist of inputs needed before kickoff, with the missing-assets examples F02 and F06 clearly labeled as invented. **Unfilled evidence gap:** the author must provide and validate the checklist instead of treating the survey as a process specification.

**Chapter 2 — Who can approve the work?** Compare the unclear approval in F01 and multiple stakeholders in F05 with the explicit approver in F04. **Unfilled evidence gap:** who decides in a real organization, when approvals must be in writing, and what happens when the approver is absent.

**Chapter 3 — What happens when scope changes?** F03 and F05 motivate a change-request decision tree. **Unfilled evidence gap:** the actual contract/process language and a concrete example reviewed by a domain expert.

This is not a recommendation that every real book should have exactly three chapters. The structure is determined by the problem these *synthetic* answers illustrate.

## E. Before / after: how to keep the claim honest

**Bad paragraph (do not publish):**

> Our research proves that most agencies lose time because clients refuse to agree on approvals. Three recurring failures explain the industry-wide problem. A standard three-step protocol fixes it.

Problems: invented "research," invented prevalence and causality, moralized account of clients, and a protocol the inputs never supplied.

**Revised paragraph for the fictional teaching example:**

> A handoff can stall when nobody knows who may approve a piece of work. In our invented exercise, one operator describes a week of delay while another says the handoff went smoothly because a single approver signed off early. Those contrasting stories suggest a useful question to settle at kickoff: who can accept or request changes to the deliverable? A practical guide would need to add a clearly labeled, independently justified approval process; these six examples alone do not prove its effectiveness.

The second paragraph is still **illustration, not published empirical evidence**. In a real guide, use checked and cleared real examples or label such scenarios as hypothetical, then support your recommendations.

## F. Reusable source-audit workflow for your own survey

1. **Record context:** purpose of the original survey; recruitment method; exact question wording; dates; number invited, reached, and answered (if known).
2. **Make a minimal working copy:** remove data not needed for this guide; assess indirect identifiers, not just names and email fields. Store the identifying key separately if it is needed for private auditing.
3. **Check publication rights and privacy:** verify what respondents were told and what reuse has been cleared. Mark unresolved quotes or cases for exclusion, not automatic publication.
4. **Assign IDs:** one stable local ID per relevant answer. Keep the exact wording privately and a cleared/redacted extract for manuscript use.
5. **Code themes and counterexamples:** one response may belong to several themes. Keep cases that complicate the central story.
6. **Separate statement types:** observation, interpretation, recommended method, or prevalence claim. Only make the claim the evidence warrants.
7. **Write a reader-first outline:** each chapter helps the reader perform a task, not revisit a survey page. Mark every unsupported section as a work item for the author.
8. **Prepare Scribora input:** create a selected, reviewed TXT, Markdown or DOCX document with source IDs and explicit caveats. The CSV coding sheet is a *planning worksheet*, not a claimed direct Scribora import format.
9. **Inspect before paying:** create an outline and sample chapters; compare every factual assertion with the authorized source and its limitations.

### Blank claim-audit template

| Proposed claim | Source IDs | Statement type | Contradictory cases | Sampling/rights limitation | Supported? | Next action |
| --- | --- | --- | --- | --- | --- | --- |
| [Your own claim] | [IDs] | [Observation / Interpretation / Recommendation / Prevalence] | [IDs or none] | [What must be disclosed] | [Yes / Qualify / No] | [Verify / Write / Exclude] |

## G. Primary references checked November 7, 2026

- Google Forms: [View and manage form responses](https://support.google.com/docs/answer/139706) — Google documents responses download as CSV, separately from book authoring.
- Microsoft Forms: [View results of your form](https://support.microsoft.com/en-us/forms/view-results-of-your-form) — Microsoft documents the Open in Excel route.
- European Data Protection Board: [Anonymisation / pseudonymisation](https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en) — replacing names with local IDs should not be described as guaranteed anonymisation.

This is educational editorial material, not a legal or statistical certification. Do not imply a platform independently checked your study or automatically secured permission.