The new-company onboarding checklist

Everything in this manual explains how to think in Ceruleo. This chapter is the one you run: the sequence we walk every new company through, in the order that avoids rework. Two weeks at a comfortable pace, less if you push. The printable checklist is at the bottom; the sections explain why each item is there and what it costs to skip.

Days 1-2: make the workspace yours before anyone sees it

Work through company settings while the workspace is still quiet. Every item here is a company-wide vocabulary that every future project inherits.

• Name, logo, branding. The company surfaces carry them everywhere, including transmittal PDFs that go to outside parties.
• Project statuses. Rename, recolor, and add to the built-in lifecycle so the words match how your company actually talks about work (see Programs, statuses, and the project lifecycle).
• RFI categories. A fixed dropdown beats free typing - decide the list now (a starter set: Design, Structural, Client, Vendor, Budget).
• Note types and templates. At minimum: a transmittal type with a People field for formal issue, and any recurring note shapes (meeting summary, decision record) with their custom fields (see Template families).
• Log templates. Define the entry types your field teams will file daily - manpower, weather, deliveries, incidents - with dropdown choices written into the template (Part 4).
• Library structure. Create the top-level folders and grant manage library to whoever owns filing standards. Empty but labeled shelves invite good filing; a blank library invites chaos (see The company library).
• Permission templates. Define "Full team," "Client," and "Fabricator" once, so inviting project members is a stamp instead of ten switches (see Members, invitations, and capabilities).
• Programs. If your projects group into larger initiatives, create the programs now so the first projects land in them.

⚙ Make it yours - none of this is irreversible, but all of it is load-bearing. An hour with the people who know your company's words saves a quarter of low-grade confusion.

Days 2-3: your first project, in the only order that works

• Create the project and set its dates first: start date and estimated end date. Schedules cannot exist without the project window, and every schedule item is bounded by it. Dates first is not a preference; it is a prerequisite.
• Name your levels. The upper three tiers are yours to rename (Venue / Zone / Scene, or whatever fits); the bottom three - Feature, Component, Part - are fixed and mean the same thing in every project.
• Build the structure. Use the Organizer, or import elements from a CSV if a spreadsheet already exists - the header row names your levels and one file fills the tree (Part 1).
• Wire the tools. Decide which tools this project runs and set the per-project defaults.
• Start the schedule early, publish it deliberately. Build it as a draft - drafts are invisible to the wider team and stay off every dashboard until the first version is published, so you can think freely. When the plan is agreed, publish (or approve): the team sees a stable published version, every publish is automatically a baseline, and later edits collect as unpublished changes without disturbing what the team relies on (Part 3). Pick the schedule's approval mode in its settings while you are there.

Days 3-5: people, by the narrowest true relationship

• Company invitations for employees and long-term contractors; project invitations for clients, vendors, and one-project partners. This is the one distinction that governs everything - the Members, invitations, and capabilities chapter is its operating manual. Promotion is always an explicit company invite; no amount of project work does it automatically.
• Grant capabilities to the few: create projects, manage templates, manage library, manage permission templates, contacts. Grant by role-in-fact, not title.
• Stamp project members with your permission templates, then adjust individuals as needed.
• Everyone installs the mobile app and signs in once, allows push notifications, and sets their notification channels (buzz and email per category, in Settings). The phone is where Pocket capture, log entries, and task completion live.
• Introduce Pocket and its email address. Each person has a personal capture address (Settings → Profile) and can whitelist senders. Capture now, file later is the habit that makes the rest work.

The first week of real work: habits over features

• Capture everything to Pocket - photos, jots from the phone, forwarded email - and file it to the right record later. Unfiled items expire; filed items live forever with the work.
• Use the right tool for the moment. The Field Guide's "Which tool when" cheat sheet (and its printable Quick Reference PDF) settles rally vs sandbox, flag vs RFI, note vs task. Share it in your kickoff.
• The log observes; the flag pursues. Field teams file log entries daily and raise flags for anything that needs chasing. Backfill honestly, reopen loudly.
• Email lives with the work. Every rally, spark, RFI, and discussion topic has its own address - CC it and the exchange becomes part of the record.
• Ask Scout. ⌘K, plain language, across everything you can see. The fastest orientation a new member gets is watching someone ask "what's overdue on our project" and get an answer with sources.
• Report bugs in-app. The Report a bug link in the sidebar reaches us directly; replies arrive in notifications. What's New announces changes as they ship.

End of week two: the check-out

Run this verification pass. If every box checks, the company is onboarded - not because the tour happened, but because the system is actually carrying the work.

• Every member has signed in on web and phone.
• The first schedule is published (not sitting in draft) and its dashboard lookahead shows real dates.
• A log was issued on a real day, by the person who will actually issue them.
• A flag was raised, worked, and resolved end to end.
• An RFI was submitted and answered - and the answer marked official.
• A transmittal went to its full recipient list.
• Something captured to Pocket was filed to a record.
• The team knows where the Field Guide and training manual live.

The printable checklist

🖨 Print this page - the navigation drops away automatically, ready for a clipboard.

Workspace (days 1-2)

• ☐ Company name and logo
• ☐ Project statuses renamed and colored
• ☐ RFI categories decided
• ☐ Note types, including a transmittal template
• ☐ Log templates for the field
• ☐ Library folders created, library manager granted
• ☐ Permission templates defined (Full team / Client / Fabricator)
• ☐ Programs created (if used)

First project (days 2-3)

• ☐ Project created with start and end dates
• ☐ Level names chosen
• ☐ Structure built or CSV-imported
• ☐ Tools wired
• ☐ Schedule drafted
• ☐ Schedule published, approval mode set

People (days 3-5)

• ☐ Company invites sent (employees)
• ☐ Project invites sent (externals)
• ☐ Capabilities granted
• ☐ Permission templates stamped onto project members
• ☐ Mobile app installed, push allowed
• ☐ Notification channels set
• ☐ Pocket addresses introduced

Habits (weeks 1-2)

• ☐ Pocket capture demonstrated
• ☐ Which-tool-when cheat sheet shared
• ☐ Daily logs flowing
• ☐ First flag raised and resolved
• ☐ First RFI submitted and answered
• ☐ First transmittal issued to its full list
• ☐ Scout demonstrated
• ☐ Check-out verification passed