INTO Consulting / Google Docs / SOW + Proposals
A reader-first specification for Statements of Work and proposals authored in Google Docs, exported as PDFs, and read by clients as working documents.
INTO Google Docs should feel like editorial working documents: airy, structured, commercially precise, and easy to review in a browser or exported PDF.
The default use cases are Statements of Work and proposals. Both should be readable without a presenter, printable without losing legal clarity, and structured enough for AI agents to generate sections without inventing layout decisions.
Use Google Docs in Pages format, US Letter portrait, 0.78in margins on a white page, the nine named styles, and Cool Light ink, fills and rules. Every value lives in templates/documents/docs-style-spec.json; this page explains them.
Use contexts/design-foundations-system.html before changing baseline rhythm, type roles, reading path, bento usage, buttons, or image/text composition in proposals and SOWs. Then apply media framework, channel data, the target media sheet, and the document template before export.
Google Docs can control paper size, orientation, margins, and page color in Pages format. Those features do not behave the same way in Pageless.
Do not design a final SOW around Pageless features. Headers, footers, page numbers, page margins, and print layout matter for client-final documents.
Statements of Work and proposals share a visual system but differ in rhythm. SOWs prioritize acceptance clarity. Proposals prioritize the recommendation and evidence path.
Proposal and SOW templates protect the client reading path, legal clarity, and export quality. They are not decorative page styles.
Cover, commercial summary, scope, phases, responsibilities, governance, acceptance, and signature blocks.
Recommendation, bottleneck, proposed workflow, current-state evidence, scope, commercials, governance, and next action.
Every template uses the white page, so every template is print-safe: 0.78in margins, headers/footers, page numbers, and PDF inspection before sending.
Landscape section only for wide pricing matrices, charts, implementation plans, or procurement appendices.
| Template Control | Required Decision | Export Check |
|---|---|---|
| Page Setup | US Letter default; A4 only as separate template. | PDF page count and margin integrity. |
| Paragraph Styles | Newsreader headings, Lexend body, mono captions/meta. | Document outline and heading hierarchy. |
| Headers/Footers | Client, project, section, page number, discreet identity. | No orphaned footer or clipped mark. |
| Table Styles | Petrol header row with IBM Plex Mono labels in inverse ink, 0.75pt line-soft rules between rows, no vertical rules, no zebra; totals on a line-strong rule; notes as a callout with a 3pt petrol left rule on the raised surface. | Readable prices and totals after export. |
| Proposal/SOW Skeleton | Conclusion first; commercials and acceptance visible. | Reader understands next action from page one. |
Choose SOW or proposal, then use the canonical template skeleton. Add sections only when they support commercial clarity or procurement review. Live templates and their audit state are listed in templates/google-templates.json; audit an export with scripts/audit-google-export.py before a template is promoted.
Use page geometry before decoration. Google Docs does not have a true layout grid, so the brand grid is conceptual and enforced through margins, tables, and recurring section structure.
Google Docs typography should preserve INTO's hierarchy while accepting that Docs has less typographic precision than HTML or desktop publishing. Every template sets all nine named styles, so Google's grey defaults never show through.
| Named Style | Spec | Use |
|---|---|---|
| Title | Newsreader 400, 30pt, text-primary | Document and cover title. |
| Subtitle | Lexend 300, 13pt, text-secondary | The lead under the title. |
| Heading 1 | Newsreader 400, 24pt, text-primary | Section title. 36pt before; 0 when a section marker opens it. |
| Heading 2 | Newsreader 400, 15pt, text-primary | Subheading: scope, fees, assumptions, governance. |
| Heading 3 | Lexend 400, 11.5pt, text-primary | Minor heading. |
| Heading 4 | IBM Plex Mono 400, 9pt, text-muted, typed in capitals | Mono label and section marker, such as 01 / SCOPE. |
| Heading 5 | IBM Plex Mono 400, 8.5pt, text-faint | Caption and source note. |
| Heading 6 | IBM Plex Mono 400, 9pt, text-muted on accent-soft | AI-GUIDANCE block in a template. |
| Normal text | Lexend 300, 11pt, text-primary | Body prose. |
Spacing sits on 6pt steps: 12pt after paragraphs, 24pt before subsections, 36pt before major sections, and 6pt table cell padding. Colours name their token in tokens/into-consulting.theme.css; the exact sizes, line spacing and hex values are in templates/documents/docs-style-spec.json. Table cells are Lexend 400 at 11pt; documents are untracked and never bold.
The SOW is a commercial control document. It should be clean, narrow, and unambiguous.
| Order | Section | Purpose |
|---|---|---|
| 01 | Cover | Client, project, date, INTO wordmark. |
| 02 | Commercial Summary | Fee, timeline, decision gate, acceptance path. |
| 03 | Scope | What INTO will deliver and what is excluded. |
| 04 | Phases | Discovery, Define, Build, Optimize with outputs. |
| 05 | Responsibilities | Client dependencies, access, owners, review cadence. |
| 06 | Governance | Security, data access, handoff, ownership. |
| 07 | Acceptance | Signatures and next action. |
The proposal should read as a short, evidence-led recommendation. It is not a sales brochure.
A client should understand the recommended system, why it matters, what it costs directionally, and what happens next from the first page.
Tables should carry pricing, scope, responsibilities, assumptions, and timelines. Avoid using tables as decorative layout scaffolds for prose.
Google Docs is for collaboration and comments. The client-final artifact should still be checked as a PDF before sending.
Every client-facing Google Doc uses the same review workflow: draft, internal review, client review, legal review when required, ready for signature, executed, and archived. Status color is only a signal when paired with text.
Use direct edit in Draft for author-owned copy. Use Suggesting mode for meaning, scope, pricing, timeline, evidence, governance, or client-visible claims.
Resolve only after the owner, reviewer, affected section, and decision are clear. Final comments use Decision: accepted, Decision: rejected, or Decision: follow-up required.
Authors edit, reviewers suggest or comment, clients comment or suggest during client review, and executed copies become view-only archived artifacts.
At v1.0 executed, preserve the signed PDF and executed source Doc. Continue operational tracking in a new linked copy.
Project Atlas Proposal
Project Atlas Proposal
Project Atlas SOW
Use in-document tables and exhibits when the reader needs to compare options, assign responsibility, understand timing, inspect workflow, judge risk, see metrics, or act on follow-up work. Color can reinforce signal only when the text still carries the meaning.
Each exhibit answers one review question. If it does not change a decision, shorten it into prose or move it to the appendix.
Every table or figure keeps a numbered caption and source note directly attached to the exhibit. Captions state the point the reader should notice.
Move wide matrices, timelines, and workflow maps to a landscape section or appendix. Do not shrink table or axis text below the Google Docs floor.
Every priority, status, risk, ownership, metric, and action state must remain readable in a black-and-white PDF without color.
| Option | Speed | Dependency Risk | Recommendation |
|---|---|---|---|
| Stabilize current flow | 2 weeks | Low | Use now |
| Replace workflow | 8 weeks | High | Defer |
Table 1. Options compare delivery speed against client-side dependency risk.
| Decision | Responsible: INTO lead | Accountable: client owner |
|---|---|---|
| Evidence | Consulted: operations | Informed: finance |
Table 2. Responsibility labels remain readable when color and initials are removed.
Figure 1. Each milestone carries date, owner, and state as text.
Figure 2. Numbered steps preserve meaning if connector color disappears.
| Scope drift | Warning: medium impact |
|---|---|
| Data access | Blocked: owner required |
Table 3. Status words carry the risk before Saffron or critical treatment appears.
Table 4. Metric name, unit, target, and date remain text-first.
| Next action | Approve pilot brief |
|---|---|
| Owner | Client sponsor |
| Status | Ready: due May 30 |
Table 5. Owner, due date, status, and next action are explicit text.
Use living Google Docs for active operations, discovery synthesis, delivery tracking, and risk review. They can carry unresolved comments and action items, but every snapshot sent outside the team must freeze state, resolve or defer threads, and pass PDF print review.
Document type, project, owner, version, status, last updated date, access posture, and next review date appear before the working body.
Record date, owner, changed section, decision, and follow-up near the front. Google Docs revision history is not enough for client review.
When a living document is distributed, freeze page numbering, resolve or defer comments, export a PDF, and keep the working copy separate.
Executed SOWs, signed proposals, invoices, legal documents, and personnel documents are not living-document types in this system.
| May 20 | Scope section updated. Decision: accepted by client sponsor. |
|---|---|
| May 21 | Risk table added. Follow-up: confirm data owner before pilot. |
| May 22 | Snapshot queued. Comments: two deferred to appendix review. |
Appendix material extends evidence depth without breaking the main reading path. Every appendix item needs a stable label, source owner, date, review job, and a main-document cross-reference that still works in printed PDFs.
Use Appendix A/B/C and Table A1/Figure B2 labels. Do not renumber main-document exhibits when appendix evidence changes.
Attach source notes to the appendix item and cite the appendix at the sentence, table, or figure that depends on it.
Landscape appendix sections are allowed for wide extracts, matrices, and screenshots when captions and page numbers remain visible.
Appendices support the current document only. Do not add legal templates, personnel records, or unrelated INTO brand material.
Main section citation: See Appendix B, Figure B2 for the operating model detail.
Status Reports, Working Agreements, and Proposal Variants are frequent, multi-stakeholder documents. They carry decisions, access posture, and review state without replacing the existing SOW or Proposal masters.
| Job | Show progress, decisions, risks, metrics, and next actions. |
|---|---|
| Cadence | Weekly or milestone-based. |
| Signal | Warning: data owner needed |
Template: templates/documents/status-report.md. Print fallback keeps owner, status, risk, and next action as text.
| Job | Define roles, meeting rhythm, decision rules, access, and escalation. |
|---|---|
| Boundary | Operational agreement only; not a legal document. |
| Fallback | Role labels remain readable without color or initials. |
Template: templates/documents/working-agreement.md. Responsibility labels print in black and white.
| Job | Review an alternate package, scope, fee, or reader view. |
|---|---|
| Master rule | Do not rewrite the master proposal unless the variant is approved. |
| Decision | Ready: approve, reject, or fold into master |
Template: templates/documents/proposal-variant.md. Changes are tabled and tied to the master version.
Discovery Summaries, Delivery Frameworks, and Risk Registers translate research, delivery structure, and material risk into reviewable client documents. They inherit the same header, review, exhibit, appendix, and print rules as Tier 1.
| Job | Convert discovery signals into findings, implications, opportunities, and next steps. |
|---|---|
| Evidence | Observation, interpretation, recommendation, and source note remain separate. |
| Appendix | Source map links to Appendix A and local citations beside claims. |
Template: templates/documents/discovery-summary.md. Findings stay source-attached and printable.
| Job | Define operating model, workstreams, cadence, decision gates, QA, and handoff. |
|---|---|
| Exhibits | Workflow and RACI grids are allowed only when they clarify ownership. |
| Signal | Ready: gate criteria defined |
Template: templates/documents/delivery-framework.md. Gates and ownership remain text-first.
| Job | Track material risks, mitigations, owners, due dates, decisions, and status. |
|---|---|
| State | Blocked: data access owner missing |
| Fallback | Status word, impact, owner, and due date survive without color. |
Template: templates/documents/risk-register.md. Critical treatment is reserved for material blocked risk.
Case Studies, Lessons Learned, and One-Sheets package evidence, learning, or a single offer for reuse. They still need approval state, source notes, review control, and black-and-white PDF fidelity before distribution.
| Job | Turn a completed engagement or proof point into a source-backed client story. |
|---|---|
| Approval | Sharing status is explicit before external use. |
| Proof | Outcome claims require source notes and approval owner. |
Template: templates/documents/case-study.md. Claims and sharing boundaries remain text-first.
| Job | Capture what changed, worked, failed, and should change next time. |
|---|---|
| Boundary | Operational learning only; not personnel assessment. |
| Action | Warning: follow-up owner needed |
Template: templates/documents/lessons-learned.md. Actions keep owner, due date, and status text.
| Job | Package one offer, service, or capability for outreach or proposal follow-up. |
|---|---|
| Structure | Problem, outcome, proof, process, timing, commercial note, next action. |
| Signal | Ready: single offer and source notes verified |
Template: templates/documents/one-sheet.md. One strong exhibit or table is enough.
These platform constraints come from official Google help sources and are recorded in the channel database.