What they are, why they matter, and how to set them up so both staff and AI know what is going on.

Groups are where everything starts

In Kibu, groups aren’t just folders. They’re the backbone of how your organization is modeled in the system.

A group decides:

- Which members live together in the same container.

- Which staff can see and document for them.

- Which tools (attendance, service records, time tracking, templates) apply.

- And how your reports will look on the backend.

If you get groups right, everything downstream — notes, service records, compliance data, billing — feels natural. If you get them wrong, you’re constantly backtracking: staff click into the wrong place, admins duplicate templates, and your reporting looks like someone spilled spaghetti on the screen.

So what does “right” look like?

The Core Principle: Program + Location

Every group should be grounded in program type and location.

Examples:

“🏖️ Day Hab – Springfield”

“👔 Vocational – Dexter”

“🏠 Residential – Maple Ave”

That’s the baseline. It’s clear, human-readable, and consistent. It also gives an AI assistant a predictable schema to work with: first figure out the program, then attach it to a place.

Sub-Programs: The Gray Area

This is where things get messy. Real programs often have “sub-programs”:

- A Day Hab with three classrooms.

- A Vocational program that runs both job coaching and skills training.

- A hybrid program with “community-based activities” and “facility-based activities.”

Do you make each sub-program its own group? Or keep everything under one umbrella?

The answer is: only split if the workflows are truly different.

- Different staff teams? → Split.

- Different schedules or compliance requirements? → Split.

- Reporting demands separate buckets? → Split.

But if the only difference is where the activity happens or what the activity is called, keep it together. Otherwise, you end up with DSPs bouncing between groups just to finish a shift’s documentation.

Note Templates: Where the Daily Notes Happen

Groups come alive through their note templates. These are forms staff fill out — and Kibu’s form builder is more powerful than most realize.

Supported fields include:

- Multiple choice

- Multi-select

- Short answer

- Long answer

- Number

- Conditional follow-ups

- And the MVP: the List

The List type is a game changer because it can hold a repeating set of fields. Example:

- Activities List

- Short answer: activity name

- Number: duration

- Single select: location (Community vs Facility)

A DSP can log multiple activities in one template without leaving the group. This has become the practical workaround for sub-programs. Instead of splitting “Community” vs “Facility” into separate groups, you capture both under one group using a list.

It’s not perfect — a Day Hab with 10 wildly different tracks might stretch the model — but for most providers it’s more intuitive than forcing staff to bounce back and forth between groups.

Settings: Don’t Just Toggle Everything On

When you create a group, you also decide which features it uses:

Service Records: Enable if documentation must tie back to compliance or Medicaid.

Attendance: Turn it on if staff actually track session presence.

Time tracking: Use it only if shifts or billable hours are relevant.

Note Template: Assign only what staff will use daily.

The temptation is to “turn on everything just in case.” Resist that. Every extra toggle adds clutter for staff. Keep it as close to the real workflow as possible.

Compliance vs Staff Reality

Here’s the unavoidable tension: sometimes compliance says “split,” but staff sanity says “keep it together.”

Example: A state waiver requires separate reporting for community vs facility hours. That pushes you toward two groups. But staff hate bouncing between them.

What’s the right call?

Our principle: optimize for staff unless compliance forces otherwise. Because if documentation is too painful, DSPs stop doing it accurately, and your compliance data collapses anyway.

The handbook (and the AI assistant that will eventually read it) should make that tradeoff explicit.

Naming Matters More than You Think

AI needs predictable patterns. Humans do too. Stick to Program – Location.

Good: “Day Hab – Derby”

Bad: “Horizons Academy Track B”

If an organization insists on branded names, fine — but keep the structure. “Horizons Academy (Day Hab – Derby)” still gives the AI enough to work with.

Staff Assignment: Less is More

Admins can see everything. Staff should only see the groups they actively work in.

Why?

Cleaner dashboards.

Fewer mistakes.

A better chance DSPs actually finish their notes.

The AI assistant should recommend minimal assignment by default.

AI’s Role in All This

Imagine the future: you give an AI a transcript of your program structure — “We run Day Hab in Bridgeport with three classrooms, a Vocational program in Derby, and Residential at Maple Ave” — and it spits back:

Groups:

- Day Hab – Bridgeport

- Vocational – Derby

- Residential – Maple Ave

Settings:

- Day Hab → Attendance + Service Records, with Activities List template

- Vocational → Service Records only

- Residential → Time tracking + Daily Note template

Staff assignments:

- Bridgeport DSPs only see Bridgeport Day Hab

- Supervisors see everything

That’s the point of writing this down. Consistency in rules makes automation possible.

Final Thoughts

Groups look simple, but they’re the skeleton of your Kibu setup. If the skeleton is crooked, everything else - templates, service records, compliance - suffers. The rule of thumb is this:

Start with program + location.

Split only when workflows demand it.

Let templates (especially lists) handle nuance.

Configure settings to match reality, not hypotheticals.

Keep staff assignments lean.

Name things consistently so AI can reason about them.

Get this right, and both staff and future AI tools will thank you: fewer clicks, cleaner data, better compliance, and a setup that scales with you instead of tripping you up.