Resources

Organize Projects and Tasks in TymzUp

A clean setup makes time entry faster and reporting easier. You do not need a complex structure to get useful results from TymzUp.

What this page helps with

Use this guide to choose what should be a project, decide when tasks are useful, and keep your setup simple enough to maintain.

  • Choosing what should be a project
  • Deciding when tasks are useful
  • Keeping setup simple enough to maintain
  • Improving time entry and reporting later
  • Avoiding over-structuring too early
Basic Idea

How projects and tasks work together

A project is the main place time belongs. A task or list item adds extra detail within a project when that detail is useful.

Projects are the main work bucket

  • A project is the primary place time should roll up.
  • Many users can start with projects only.
  • Projects usually match the level people want to review in reports.

Tasks add detail when it helps

  • A task or list item adds extra detail within a project.
  • Tasks should be added when they improve reporting or clarity.
  • If project-level reporting is enough, tasks may not be necessary.
Projects

What should be a project

Projects are best used for the work bucket time should roll up into and the level that matters most in reporting.

Examples

Good project examples

  • Client Work
  • Internal Admin
  • Operations
  • Personal Development
  • Specific client or department names when needed
Use Projects For

The level that should appear in reports

  • The work bucket time should roll up into
  • The category people want to review in reports
  • The distinction that matters for billing, visibility, or workload review
Keep It Practical

Only add more projects when the distinction matters

Do not create too many projects unless those differences will actually be useful in reporting later.

Tasks

When tasks help

Tasks or list items are optional and work best when they separate types of work inside a project and keep reporting readable.

Use tasks when they add clarity

  • Separate types of work inside a project
  • Help reporting stay readable
  • Help teams use a shared structure
Meetings Development Admin Support Review Discovery

Tasks may not be necessary

  • Solo use
  • Very light tracking
  • Cases where project-level reporting is already enough
Setup Choices

Start simple, then add detail only when needed

The best setup is the one people will actually maintain. Most teams should start lighter than they think.

Simple Setup

Better for early use

  • Fewer projects
  • Few or no tasks
  • Faster to maintain
  • Good for solo consultants or early setup
Detailed Setup

Better once patterns are clear

  • More project separation
  • Shared tasks or list items
  • Better for team consistency
  • Useful when detailed reporting becomes clearly valuable
Examples

Example ways to structure TymzUp

These examples are starting points. Use the level of detail that matches how your work is actually reviewed.

Solo Consultant

Keep client work easy to review

Projects

  • Client A
  • Client B
  • Internal Admin

Tasks

  • Optional: Meetings
  • Optional: Delivery
  • Optional: Admin
Small Service Team

Use shared work types when they help

Projects

  • Client Work
  • Internal Operations
  • Business Development

Tasks

  • Discovery
  • Delivery
  • Support
  • Review
Internal Business Use

Track major internal work buckets first

Projects

  • Operations
  • Admin
  • Training
  • Department-specific work if needed

Tasks

  • Optional, only when they improve reporting clarity
Workflow Impact

Why structure matters later

Project and task setup affects how easy the Time Entry form is to use and how clear reports will look later.

Where structure appears in the product flow

Settings → Projects/Lists → Time Entry → Reports

  • Clear structure makes Time Entry easier to use.
  • Useful naming keeps reports cleaner and easier to review.
  • Good setup makes exports, review, and billing support simpler later.
Common Mistakes

Common setup mistakes

  • Creating too many projects too early
  • Using tasks when project-level reporting is enough
  • Naming projects too vaguely
  • Building a structure no one will actually maintain
  • Changing the setup constantly before reporting needs are clear
Best Practices

Keep the structure useful over time

  • Start with a small number of clear projects.
  • Add tasks only when they improve reporting.
  • Use names that will still make sense in reports later.
  • Review your structure after a few weeks of real use.

Clear structure makes the rest of the workflow easier

Once your project structure is clear, time entry becomes easier and reports become more useful.