Before you start
- A Cygnetree workspace
- A rough list of your current work stages
Begin with outcomes, not CRM words
You do not need to know what a CRM is. Write down the questions you need answered each morning:
- Who is waiting for me?
- Which inquiries need a response?
- Which work is likely to book?
- What must happen before the next appointment or deadline?
- What has been delivered, paid, cancelled, or archived?
Cygnetree's people, projects, pipelines, tasks, messages, and documents exist to answer those questions. A starter can demonstrate a sensible setup, but it never restricts the builders.
Model the people around the work
Use one People record for each real person, household, business, or venue. Add roles such as lead, client, vendor, or partner without copying the record. Connect related people and businesses, then give each project participant a project-specific role and visibility.
Do not create a new person just because the same client returns. Create another project and attach the existing person. Merge only after reviewing identity, relationships, portal access, migration source IDs, and affected work.
Choose a project boundary
A project is the work context your team and invited people share. Depending on the business, it may be an engagement, case, event, job, booking, campaign, service period, or recurring visit.
Create a separate project when the work has a distinct agreement, outcome, timeline, or set of participants. Keep one project when splitting it would make communication, files, money, or responsibility harder to understand.
Build a pipeline that answers questions
Start with one pipeline and five to eight stages. Each stage should describe a real state, not a calendar year or vague activity. For example:
- New inquiry
- Qualified
- Proposal or scope
- Decision pending
- Booked
- In progress
- Delivery and follow-up
- Complete or closed
Add stage guidance for the exit condition, required checklist, likely next action, and warning signs. Use event dates and saved views for years, seasons, locations, owners, service types, and other dimensions instead of multiplying pipelines.
Moving existing work between pipelines is previewed and explicit. Preserve the source stage during migration; improve the model only after source reconciliation.
Add detail only when it earns its place
Use custom fields for facts the team repeatedly filters, merges into communication, validates, or reports. Use tags for flexible labels. Use tasks for actions, milestones for externally meaningful dates, notes for internal context, and approvals when a named decision must be recorded.
Avoid fields that merely repeat a message, document, or stage. More fields do not create a better system when nobody trusts or maintains them.
Review the setup after real use
After the first week, review:
- stages where work waits without a clear owner;
- repeated manual actions that should become a basic automation;
- custom fields that are blank or ambiguous;
- saved views people recreate by hand;
- portal items clients or vendors cannot find; and
- notification or dashboard choices that do not match each member's role.
Change the workspace deliberately. Templates and versions make experimentation recoverable; they do not replace a short conversation about how the business actually works.