Float

Float doesn't have a headline AI capability -- its real mechanism is the visual drag-and-drop scheduling grid for allocating people's time, backed by Reports that show budgeted vs. scheduled vs. logged hours and per-person utilization.

Practical Details

Planning decisions in Float come from reading those utilization numbers and the schedule grid directly, not from AI-generated suggestions -- confirm current documentation directly if you're evaluating a specific AI-labeled feature.

Actionable Considerations

• Evaluate Float on its scheduling grid and utilization reporting, not on AI capabilities it doesn't market as a core feature
• Use the People report's utilization percentage as your real planning signal, not an assumed AI insight
• Confirm any AI-labeled feature directly in current documentation before relying on it

Float scales less through enterprise infrastructure and more through how well its grid handles more people and projects on one screen. Agencies running many people across dozens of concurrent client projects lean on Departments and custom tags (by skill, office, or discipline) to filter the schedule down to a usable view instead of scrolling one long grid. There's no hard seat cap baked into the product — the real limit is visual: a schedule with hundreds of rows and months of allocations gets harder to scan even with filters, which is why larger teams typically split the view by department or role rather than planning the whole company on a single screen.

Practical Details

Float is priced per person scheduled, so growth in Float is mostly a headcount and filtering question rather than an infrastructure one. Agencies with multiple offices or practice groups usually set up Departments to mirror that structure, then rely on saved views and tags (e.g. "senior," "contractor," "available for new work") to keep the day-to-day planning screen manageable as the roster grows.

Actionable Considerations

1. Set up Departments and tags early — retrofitting a tagging structure onto a schedule with hundreds of existing allocations is tedious.
2. Give each team or office lead a filtered/saved view of just their people, rather than having everyone scroll the full company schedule.
3. Revisit your utilization reporting cadence as headcount grows — a weekly review that works for 20 people usually needs to become department-level once you pass 100.

Float's schedule and reports data can be exported as CSV from the Reports tab — the actual schedule grid isn't built as a general-purpose data source. There's no SQL console or ad hoc query tool; the closest thing to a raw data feed is Float's REST API, which is mainly used by integrations rather than for one-off reporting. Two-way task integrations with Asana, Trello, Jira, and Teamwork pull tasks into Float as unscheduled items, but they don't auto-allocate hours — someone still has to drag each task onto a person's calendar and assign dates in Float itself.

Practical Details

The Reports tab is where most exporting actually happens: Project reports compare budgeted, scheduled, and (once time tracking is turned on) logged hours, while People reports show a per-person utilization percentage — the number most agencies check weekly to see who's over- or under-allocated. Both can be exported as CSV for use outside Float.

Actionable Considerations

1. Use the People report's utilization percentage, not the raw schedule grid, when reporting availability upward — it already accounts for time off and part-time hours.
2. If you need allocation data in a BI tool or spreadsheet, export the CSV from Reports rather than trying to scrape the schedule view, which isn't designed for bulk extraction.
3. Remember that task imports from Asana/Jira/Trello create unscheduled placeholders — budget time to actually assign hours and dates to them in Float, since the integration won't do it for you.

Setup means importing your team roster, creating Projects, and setting up Departments and tags (by office, skill, or discipline) before entering allocations -- retrofitting a tagging structure onto an existing schedule with hundreds of allocations later is tedious.

Practical Details

Agreeing on allocation conventions (tentative vs. confirmed status, hours vs. percentage) during setup, not after rollout, avoids inconsistent data that undermines reporting later.

Actionable Considerations

1. Set up Departments and tags before entering allocations at scale, not retroactively
2. Agree on tentative/confirmed and hours/percentage conventions as a team before go-live
3. Pilot with one representative team first to validate the setup before rolling out company-wide

The concrete outcome is visibility into who's over- or under-allocated via the People report's utilization percentage, which most teams check weekly -- not an abstract "planning clarity" claim.

Practical Details

That value depends on the team actually agreeing on and following allocation conventions (tentative vs. confirmed status, hours vs. percentage) consistently -- inconsistent entry undermines the reports' accuracy regardless of how good the tool itself is.

Actionable Considerations

1. Agree on allocation conventions (tentative vs. confirmed, hours vs. percentage) before rollout, not after
2. Check the People report's utilization percentage weekly as your real, concrete success metric
3. Revisit conventions if reports start looking inconsistent, since that usually traces back to entry habits, not the tool

Two-way task integrations with Asana, Trello, Jira, and Teamwork pull tasks into Float as unscheduled items -- they don't auto-allocate hours, so someone still has to drag each task onto a person's calendar and assign dates manually.

Practical Details

For anything beyond those native task integrations, Float's REST API is the practical option, mainly used to build custom integrations rather than for ad hoc reporting -- the Reports tab's CSV export is the simpler path for pulling data out.

Actionable Considerations

• Budget time to manually assign hours and dates to tasks imported from Asana/Jira/Trello, since the integration won't do it for you
• Use the Reports tab CSV export for data extraction rather than building against the API for a one-off report
• Reach for the API only when you need a genuinely custom integration beyond the native task connectors

Float is a resource scheduling and capacity-planning tool -- a visual grid for allocating people's time across projects -- not a full project management or task-tracking platform; it's meant to sit alongside tools like Asana or Jira, not replace them.

Practical Details

Pricing is per person scheduled, so cost scales directly with headcount rather than usage or feature tier, which matters when evaluating cost for a growing team.

Actionable Considerations

• Confirm Float fits as a capacity-planning layer alongside your existing task-management tool, not a replacement for it
• Estimate cost based on total headcount to be scheduled, since pricing is per person
• Decide who owns the schedule (a resource manager or studio lead) before rollout, since Float doesn't dictate that structure for you

Float's practical access control is role-based (e.g. Admin vs. Member-level access) combined with project-level visibility, controlling who can view or edit schedules and sensitive project/client information.

Practical Details

Confirm current documentation directly if you need formal audit trails or enterprise-specific controls like SSO, since availability varies by plan tier.

Actionable Considerations

1. Map roles to actual responsibilities (who can edit allocations vs. only view them) rather than granting broad access by default
2. Review visibility settings for sensitive client or project information specifically
3. Confirm your plan tier includes any enterprise-specific access features before assuming they're active

Float's scheduling grid is drag-and-drop and deliberately simple — most people can place an allocation, resize it, or split someone's day between two projects within minutes of opening the tool, with no formal training needed. The harder part of onboarding isn't the interface, it's agreeing on conventions: whether "tentative" and "confirmed" status mean the same thing across teams, how time off gets logged, and whether allocations are entered as hours or percentages. Float's help center documents the interface well; the scheduling conventions are something each team has to settle on its own.

Practical Details

Support is primarily self-serve — a searchable help center with articles and short video walkthroughs — plus in-app chat or email support for account and billing questions. There's no bundled certification program or dedicated onboarding consultant by default; most teams are expected to configure Departments, tags, and permissions themselves using the documentation, though larger accounts sometimes get a named contact.

Actionable Considerations

1. Agree on allocation conventions (tentative vs. confirmed, hours vs. percentage) before rollout, not after — fixing inconsistency across an existing schedule is painful.
2. Point new users to the help center's videos on Reports and Time Tracking specifically; the core scheduling grid rarely needs a tutorial.
3. Nominate one internal owner, usually a resource manager or studio lead, to answer scheduling-convention questions, since Float support won't weigh in on how your team should use tentative vs. confirmed status.