Onboarding cost scales with locations, not customers.

Kyle's three buckets, 25 pain points. Click any row for the solution. Display numbers renumber as buckets change — the small grey ref never does, so quote that one.

Done Already shipped — report it, do not re-litigate itIn-Dev Being built right nowBuild Build right after the onsiteDesign Use the onsite to get to the best functional behaviourClarify Needs an answer before it can be scoped at allBlocked Nothing we can do about it without a major endeavour
Groups at scale · ref A1
A1 Effort L Front EndBackend Design

Activation is one group at a time

What it costs today

EWC had 150 groups to flip at once, done individually. No bulk operation anywhere in the go-live path.

Do you want me to tell it? Individually.Kyle Daniel
Proposed solution

Multi-select plus one action panel — select across filters, then act on the whole set at once

  1. Checkbox per row, select-all on the header, and select-all-matching for the whole filter — not just the visible page.
  2. Selection persists across filter and search changes, so a set can be assembled in several passes.
  3. One action panel on the selection: change status, message owners, resend T&Cs, enable billing, export.
  4. Going Active runs the readiness check (B4) first and holds incomplete groups in Draft with the reason.
  5. Selection survives the action, so operations chain on the same set.
Front door

② Group Operations page

The wave front door. Corporate-paid batches, driven by an operator.

Moves with
Open questions
  • Is Active → Draft irreversible, and does fixing reversibility beat building bulk tooling?

Kyle + Graham

Design space

Group Operations

The multi-select and action panel below. Select rows, or use the header checkbox, then open any action — each one confirms what will happen before it runs.

Change status bulk action, with the readiness hold-back breakdownGroup OperationsChange status — 3 selected, 1 will activate, 2 held back with the reason each was heldOpen the prototype
Groups at scale · ref A2
A2 Effort L Front EndBackend Design

Every new group is configured by hand

What it costs today

Attributes, collections, strategies and settings set one at a time — "most of what makes a wave expensive."

Configure this one like the others.The interaction Tim and Kyle keep describing
Proposed solution

Bulk-add group custom attributes and assign the OU across a selection — one operation instead of one visit per group

  1. Select the groups, set their Organizational Unit once for the whole set.
  2. Add group custom attributes in bulk — key and value written to every selected group.
  3. Applies to the selection from A1, so the same set can be configured and activated in sequence.
  4. Every write lands in the group change log, so a bad bulk edit can be traced and reversed.
Front door

Group Operations page

Attributes and OU are what make a group behave like its siblings.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

Bulk OU assignment and the attribute editor below. Note the knock-on: attribute-defined collections would remove the 50-group cap entirely.

Configure groups bulk action — OU plus group custom attributesGroup OperationsConfigure groups — bulk OU assignment and group custom attributes, with the note on how attribute-defined collections remove the 50-group capOpen the prototype
Groups at scale · ref A3
A3 Effort M Backend Design

Billing is enabled per group, then re-keyed monthly

What it costs today

Two touches per group, then hand re-keyed across three systems. Foxboro: 54 locations configured manually. 242 Stripe addresses hand-entered.

Proposed solution

Bulk billing configuration — payment method, pricing and commitments set across a selection in one operation

  1. Payment method and terms chosen once: automatic card payment, or invoice with terms.
  2. Pricing period selector — previous, current or next month — so a wave can be priced ahead of go-live.
  3. Base fees, per-message rates, minimum spend and corporate credit set for the whole selection; blank fields are left untouched.
  4. Address and payment pull from the signup record (A4) wherever one exists.
  5. The Stripe write happens once per operation; failures return as a per-group list.
Front door

Group Operations page

Also the remediation tool for the EWC ~1,100-vs-97 billing-accuracy gap.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

The bulk billing panel below — payment method, the month selector, and every priced line item applied across the selection.

Configure billing bulk action — payment method, pricing and commitments across the selectionGroup OperationsConfigure billing — payment terms, billing period, base fees and commitments applied to every selected group in one operation instead of two touches eachOpen the prototype
Groups at scale · ref A4
A4 Effort M Front EndBackend Design

Card-on-file gates launch and nothing chases it

What it costs today

TLE stalled for weeks waiting on a card nobody was asking for.

Proposed solution

Capture the card during self-serve signup, before it can become a blocker

  1. Card capture is a required step in the in-app signup form, before submit.
  2. Owner-only permission is the thing in the way — see C6.
  3. A group cannot reach Active without a card on file.
Front door

① Self-serve signup

The preferred-vendor front door. The franchisee is already signed in.

Moves with
Open questions
  • Only Owners can enter payment details — and Owner is blocked in import.

Graham (see [[A8]])

Design space

Franchisee Signup

The Billing details step inside the signup flow — billing email, address and payment method captured before first access, with the step gated so a group cannot proceed without a card.

Billing details step — card on file before the app opensFranchisee SignupBilling details — required before access, with Invite, Login, Account and Terms already complete behind itOpen the prototype
Groups at scale · ref A5
A5 Effort L Front EndBackend Design

No reliable signal that a location signed up

What it costs today

Discovery is accidental. EWC dropped 23 centres mid-flow. Picklr Bluffdale and Lehigh went live and nobody told them.

Proposed solution

A team-scoped registration link, emailed to the location, so signup attaches to the right Team on arrival

  1. The real fix is upstream: each location receives an email carrying a URL scoped to its parent Team.
  2. Registering through that URL attaches the location to the correct Team — no guessing, no post-hoc reconciliation.
  3. Only then is an arrival queue meaningful: signups land against a known Team, with an owner and an SLA.
  4. Row shows the registry check result (C1) and hosting completeness (A8).
Front door

① Self-serve signup

Not a quick win — tokenized team-scoped invite links plus the email path make this a substantial build.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

The Owner column on the Groups table, carrying the three states a signup can be in — signed up, invited and unanswered, or never asked — with the bulk actions that act on whichever set you select.

The signal lives in the Owner column on the Groups table — not in a queue nobody opens. Three states, readable at a glance across the whole estate: a name and email means that franchisee signed themselves up and is live; “invited Aug 8” means the invitation went out and has not been accepted, so it can be chased or re-sent in bulk; “no owner user” on a red Setup Required row means nobody was ever invited — which is how EWC dropped 23 centres and how Picklr Bluffdale and Lehigh went live without anyone telling them. Sort or filter on the column and the ones that need chasing group themselves; select them and Message owners or Resend T&Cs acts on exactly that set.
Groups table — the Owner column reading signed up, invited, or nothing at allGroup OperationsThe Owner column — a name and email means they signed up, “invited Aug 8” means the link went out and is unanswered, “no owner user” means nobody was ever askedOpen the prototype
Groups at scale · ref A7
A6 Effort L Backend Design

Bulk-uploaded users land in a password reset

What it costs today

Invites suppressed because they can’t be scheduled; status invisible and not bulk-resendable. ~10 support tickets from one 540-user Victra import. 12+ "resend the invite" requests over 2.5 years.

Proposed solution

A bulk Message Owners action — pick a template, send now or schedule it to fire with the wave

  1. One send addressed to the owner user on each selected group record — no more one-at-a-time password-reset emails.
  2. Pick from named templates: go-live announcement, welcome, card-on-file, training invitation.
  3. Send now, or schedule to a date and time so the invite fires with the wave instead of on import.
  4. The panel states its own reach before you confirm — how many owners will receive it, and how many groups have no owner user at all.
  5. Groups with no owner are surfaced as a count, not a silent failure.
Front door

Both front doors

Self-serve covers hand-raisers. Waves still need staged invites.

Moves with
Open questions
  • Batch-release or self-service as the target invite model? Engineering is blocked on this.

Shane + Jean

Design space

Group Operations

The Groups table carrying invite state per group — loaded with the invite held, invited and unanswered, or never asked — next to the scheduled status legend on rows with a pending flip. Message owners is the control: hold and release manually, send now, or release on a date.

Load the owners, then decide when each wave gets invited. The CSV import writes every owner email onto its group record and sends nothing — so a whole brand can be loaded in one pass. The invitation becomes a template in Message owners with three release modes: hold and release manually, send now, or release on a date. Until it is released the Owner column reads loaded · invite held, so an unsent invite is visible rather than assumed. That is what stops 540 Victra users landing in a password reset on import day, and it removes the reason invites were being suppressed in the first place.
Scheduled status changes now read on the row. A group scheduled to flip shows its current status pill with the pending change beneath it — Draft and then Active Sep 22. Groups with nothing scheduled show only the pill, so the column costs no extra space in the common case. Hover for the reason and the exact date.
Groups table — held invites and a scheduled status changeGroup OperationsOwners loaded from CSV with the invite held, alongside a Draft group scheduled to Active Sep 22 — both states visible on the row instead of assumedOpen the prototype
Groups at scale · ref A10
A7 Effort M Front EndBackend Design

Group custom attributes need SFTP and one specific person

What it costs today

Changeable only via the SFTP transformer. CSMs cannot self-serve. Hits 100% of QSR brands on Franchise Hub.

Proposed solution

In-product attribute editing, with bulk apply from the Group Operations page

  1. Group custom attributes editable in-product by CSMs — no SFTP, no transformer.
  2. Bulk apply across a selection from the Group Operations page.
  3. Change log, so a bad bulk edit can be traced and reversed.
Front door

② Group Operations page

Per-group editing and bulk apply are the same surface.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

The Configure groups action — bulk OU assignment and group custom attributes applied across a whole selection, editable in-product instead of through the SFTP transformer.

Configure groups — bulk OU and group custom attributesGroup OperationsConfigure groups — group custom attributes and OU applied in bulk from the table, with no SFTP transformer and nobody specific to wait forOpen the prototype
Groups at scale · ref A14
A8 Effort M Front EndBackend Design

Hosting data is gathered piecemeal after submission

What it costs today

47 of 63 Picklr numbers came back "Unable to Host." ~$6,300 in goodwill credits, 25+ Twilio threads. The reason a wave desynchronizes.

The longest and least predictable step.On hosting, Kyle’s appendix
Proposed solution

One intake form that branches on how the number is acquired, checks host-ability before asking anything else, and captures the signer’s authority

  1. Screen one is a single question — keep your calls, move the number, or get a new one. Acquisition decides whether an LOA is needed at all.
  2. The carrier check runs immediately on the number and gates the rest of the form: hostable, mobile, not hostable, or check failed.
  3. Host and port collect the LOA set — legal name as it appears on the phone bill, structured service address including County, signer name, email and role.
  4. A non-skippable confirmation that the signer is authorised on the account. A name alone is what got Primrose Rockland rejected at T-1 day.
  5. Buy is three fields and no LOA. Nobody sees fields for a path they are not on.
  6. Fields are carrier-agnostic, so nothing is thrown away at the Bandwidth migration.
Front door

Both front doors

Same component, two entry points: the franchisee at signup, or onboarding on their behalf from the group record.

Moves with
Open questions
  • Does this live inside the self-serve signup flow, standalone, or both? — Seba
  • Final field list against Bandwidth’s current requirements — Kyle
  • Can importTnChecker be called synchronously from the form, or does it need a queued check? — Lucas
  • Who generates and sends the LOA once the form submits? — Kyle
  • Does Onboarding need a bulk/CSV variant in v1? — Kyle, Jean

Tim — confirm before the session

Design space

Group Operations

The status columns on the Groups table. Hosting and Campaign are read per group and hover for the full value, so an unhostable number or an unverified campaign is visible on the row rather than arriving in a carrier thread weeks later.

Solved by status columns on the table, not a new surface. Hosting reads Hosted, In process, Unable to host or n/a per group; Campaign carries the campaign name with a green check when the number is on a verified campaign and a red cross when it is not. Hover either for the full value and the reason. That is the whole fix for visibility — 47 of 63 Picklr numbers came back “Unable to host” and nobody could see it in one place; now you filter Hosting to that value and the affected groups are the answer.
Hosting, Campaign, T&Cs and Billing status columns on the Groups tableGroup OperationsThe status columns — Hosting and Campaign read per group, so “Unable to host” and an unverified campaign surface on the row instead of arriving in a Twilio thread weeks laterOpen the prototype
Brand enablement · ref B3
A9 Effort L Front EndBackend Design

Four settings across three surfaces govern how groups send

What it costs today

Nine combinations, four valid. At least one production team currently holds an invalid combination.

Proposed solution

Configuration Profile selector — pick one of four by name, and the settings follow

  1. Four named profiles replace nine ad-hoc combinations of four settings.
  2. Pick one at team creation; the underlying settings follow automatically.
  3. Invalid combinations become unreachable; existing teams get audited once.
Front door

Team creation checklist

Also the home for B2.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Team Creation

The Configuration Profile selector at team creation — four named profiles, the three settings each one writes, and the contradictory combination made unreachable.

Configuration Profile selector — four named profiles replacing nine combinationsTeam CreationConfiguration Profile — four named profiles, each showing the three settings it writes, chosen once at creation instead of assembled from nine reachable combinationsOpen the prototype
Brand enablement · ref B4
A10 Effort M Front EndBackend Design

Short URL is bought manually in Cloudflare

What it costs today

Done via OnePass, easy to forget, and traffic gets flagged without one. "You just got to know you got to do that."

You just got to know you got to do that.Kyle Daniel
Proposed solution

Search and buy in-product via the Cloudflare Registrar API

  1. Search availability and buy the short domain from inside Voxie.
  2. Part of the team creation checklist rather than tribal knowledge.
  3. Ownership and expiry visible on the team record.
Front door

Team creation checklist

One-time per brand, and currently invisible until it bites.

Moves with
Nothing else depends on it
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Team Creation

The Short URL step at team creation — availability check, purchase, and the domain recorded against the team, alongside the required HubSpot Company ID on the same screen.

Short URL search and buy at team creationTeam CreationShort URL — searched and bought in product at creation, so the domain is owned and tracked instead of remembered as a Cloudflare errandOpen the prototype
Groups at scale · ref A18
A11 Effort L Front EndBackend Clarify

Terms & Conditions are all-or-nothing across a Team

What it costs today

One document applies to every Group. Primrose wants in-app signing for new owners without making hundreds of DocuSign signatories re-sign — and today there is no way to express that.

Wave 1’s acceptance stays valid and frozen against the document they actually signed.Seba, Aug 12
Proposed solution

Let a document target a subset of Groups, and let more than one document be active at once — legacy acceptances stay frozen against what was actually signed

  1. A Group sits in one of three states: no terms, a single document, or one specific active document out of several.
  2. Creating a document asks who it applies to — all Groups, a cherry-picked list, or net-new Groups from the effective date.
  3. Wave 1 stays on the document it signed, marked Legacy: kept for audit, not editable, never re-triggered.
  4. The list view gains an Applies to column, and a Coverage view shows which Groups answer to which document.
  5. Corporate-owned Groups stay exempt and short-circuit before any targeting is evaluated.
Front door

Team creation checklist

Franchise Hub only. Legacy Teams migrate first. Builds on the Draft/Active/Paused/Archived lifecycle already being scoped.

Moves with
Open questions
  • Can a Group ever be in the target set of two Active documents at once? Recommend preventing overlap — needs explicit confirmation, not an assumption.
  • What covers Groups in no active document — simply unblocked, or must one document always be the catch-all?
  • Does “net-new Groups only” require a real concept of Group creation date or onboarding wave? The Primrose case implies future Groups auto-included, which is meaningfully harder than a one-time cherry-pick.
  • Precedence between an OU cascade and a directly targeted document, once both exist.
  • Feasibility and timeline — not yet scoped in Linear.

Lucas — feasibility; Kelsey + Shane + Seba on the model

Design space

Terms & Targeting

The Terms & Conditions list with the Applies to column — more than one document active at once, each targeting its own groups, with legacy acceptances frozen against the document actually signed.

Terms & Conditions list with the Applies to column and three documents live at onceTerms & TargetingThree documents live at once with an Applies to column — legacy frozen for audit, published targeting net-new groups, a draft cherry-picked, and 6 groups covered by nothingOpen the prototype
Groups at scale · ref A9
B1 Effort S Front EndBackend Done

The T&C gate can freeze locations with no way out

What it costs today

~60 Picklr locations frozen because the master file held generic emails, not human owners. No admin kill switch, no "Not Accepted" export.

Proposed solution

Kill switch plus export — and self-serve signup fixes the root cause

  1. Admin override to unfreeze a location without waiting on acceptance.
  2. Export of every group in Not Accepted, with the address it was sent to.
  3. Root fix: signup guarantees a real human owner email exists (front door ①).
Front door

Both front doors

The kill switch is remediation. The form is prevention.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Terms & Targeting

The Terms & Conditions surface with the Acceptances and Not Accepted tabs — every group that has not accepted, and the reason each one cannot be reached.

Terms & Targeting prototypeTerms & TargetingTerms Acceptances — the Not Accepted list, and why nobody can signOpen the prototype
Groups at scale · ref A11
B2 Effort S Front End Build

50-group selection cap on collections

What it costs today

No paste-a-list. Makes TLE (450+), EWC (150 at a time) and Primrose (600) unworkable by hand.

Proposed solution

Define collections by group custom attribute instead of a hand-picked list — an attribute-defined collection has no ceiling

  1. A collection defined by an attribute value rather than an enumerated list of groups.
  2. Every group carrying the value belongs to it, so 450 or 600 groups join without anyone picking them 50 at a time.
  3. Depends on bulk attribute writing (A2) — set the attribute once across the wave, the collection follows.
  4. The cap itself stops mattering rather than needing to be raised.
Front door

Group Operations page

The bulk attribute action in A2 is what makes this work.

Moves with
Open questions
  • Can collections accept an attribute-based definition, or is the membership model strictly a list?

Graham

Groups at scale · ref A13
B3 Effort S Backend Build

No welcome email, no go-live email

What it costs today

Everything sent by hand, one location at a time: 18 byte-identical emails, 5 within 15 seconds. 11 launch notifications, 6 at the same timestamp.

Proposed solution

Trigger Jean’s two templates on state change — both are already written

  1. Welcome email fires when a signup is received; go-live email when status becomes Active.
  2. Jean’s two templates, wired to the state change. No new copy needed.
  3. Sent to the owner email captured at signup, with the CSM copied.
Front door

Both front doors

Fixes "went live and nobody told them" for both motions at once.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

The Message owners action — template selection, the three release modes, and the reach counters that separate owners who can be contacted from groups with nobody on the record.

Message owners — five templates and three release modesGroup OperationsMessage owners — five templates including the go-live announcement, with hold, send now or release on a date as the timing controlOpen the prototype
Groups at scale · ref A15
B4 Effort M Front End Build

Nothing confirms a group is ready before it flips live

What it costs today

Groups go live incomplete, and the failures are customer-visible.

Proposed solution

A readiness check that gates the bulk activate — nothing flips live until it passes

  1. Change status runs the check before anything moves: groups that pass flip, groups that fail stay exactly as they were.
  2. Failures are broken into named reasons — no owner user, T&Cs not accepted, no phone number, not in a verified campaign, billing incomplete — counted per operation.
  3. Read from the columns already on the row, so it needs no new platform state; the same filters narrow the selection before you ever open the action.
Front door

Group Operations page

The headline column. Read-only in v1 — it reports, it does not gate.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Group Operations

The Groups table as the decision surface. Every readiness signal is a column on the row and a filter above it, so onboarding can isolate any permutation — hosted but not on a verified campaign, cleared to send with no T&Cs, a number assigned but billing incomplete — and then flip only that set. The Change status action re-runs the same check on submit and holds back anything that still fails, naming the reason.

Groups table — every readiness signal on one row, and the filters that isolate any permutationGroup OperationsEvery signal on one row — owner, number, use for sending, vendor, hosting, campaign, T&Cs and billing — with a filter per column, so onboarding decides when to flip based on the actual permutation rather than a guessOpen the prototype
Groups at scale · ref A16
B5 Effort L Front End Build

Onboarding state lives in six Google Sheets

What it costs today

Six trackers, hand-maintained per brand. Eight Notion pages exist only to say "go update the tracker."

Proposed solution

The ops page retires them. One row per group, live, instead of six hand-maintained trackers

  1. Every field the trackers hold already exists in Core, Twilio, Bandwidth or Stripe.
  2. Surfacing existing data is exactly what Lucas can ship without Graham.
  3. Tim: “you’ve gotten rid of a spreadsheet, because now that table is telling us all of the critical questions.”
Front door

Group Operations page

Also absorbs Kelsey’s billing cockpit — budget already allocated later in the year.

Moves with
Open questions
  • Cost of the TCR-campaign visibility column — never sized.

Lucas — in grooming

Design space

Group Operations

The Groups table as the record of onboarding state — sixteen columns visible of twenty-two, each one a milestone that used to live in a spreadsheet, with the column picker saving the layout to the team.

Groups table — onboarding milestones as columns on the group recordGroup OperationsThe same table read as onboarding state — each column a milestone the six trackers were maintaining by hand, written by the system rather than typedOpen the prototype
Brand enablement · ref B2
B6 Effort S Front End Build

Default group status on creation is a hidden team setting

What it costs today

The root cause of the A1 status mess. Bulk import silently defaults every group to Active because of it.

Oh no, I did not know this.Kyle, when Seba showed him the setting
Proposed solution

Surface it at team creation, inside the configuration profile selector

  1. The setting moves out of hidden team settings and onto the creation screen.
  2. Shown inside the configuration profile selector (B3), with its consequence stated in plain words.
  3. Import respects it explicitly instead of silently defaulting to Active.
Front door

Team creation checklist

A Bucket B item causing a Bucket A problem. Pull it out of Priority 2.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Team Creation

The default group status stops being a setting anyone has to find. It is implied by the use case chosen at team creation and shown on the profile card — Single Brand Number and Hybrid, Open by Default imply Active; Local Numbers Only and Hybrid, Activate to Send imply Draft. Named against a real brand, so the choice is recognisable rather than abstract.

Configuration Profile — New groups status implied by the use case chosen at creationTeam CreationNew groups: Active or Draft is implied by the use case you pick — not a hidden team setting somebody has to know aboutOpen the prototype
Groups at scale · ref A12
B7 Effort XL Backend Blocked

Group status drives nothing

What it costs today

Enrolment into collections is manual, per group. Every activation needs a second manual step.

Proposed solution

Deferred. Active auto-enrolling into collections changes how the platform behaves — that is Graham, and Aug 10 ruled it out of the sprint

  1. Seba’s Aug 5 proposal: a collection that only accepts Active groups enrols each new one automatically.
  2. It is platform logic, not a UI — squarely on Graham’s side of the build line.
  3. Aug 10: “we cannot allocate time the sprint after.” Onsite discussion topic, not a build.
Front door

Onsite discussion

The ops page makes the missing enrolment visible in the meantime.

Moves with
Open questions
  • Worth spending onsite time on the ideal behaviour when nobody can build it this sprint?

Seba + Graham

Design space

To design

Nothing to build in September. If the room wants it specced, the artefact is a brand-level mapping model — not a screen.

The UI for B7 lands hereNot designed yet.
Groups at scale · ref A6
C1 Effort S Front EndBackend Design

No fast way to check whether a group already exists

What it costs today

Duplicates inflate group counts — and counts drive billing. Missed activations hide in the same gap.

Proposed solution

The phone number is the duplicate key. The intake form looks it up in Voxie before the carrier check, so a duplicate is caught before the Group exists

  1. Nobody is asked for an External ID — a franchisee does not know theirs. The number they are already typing is a better key than one they would have to look up.
  2. Three signals are checked at once: the number itself, brand plus location name, and the service address on file.
  3. Exact match on the number blocks submit and routes to the CSM who owns that Group, showing its External ID, owner and status.
  4. Near match warns and offers the candidates — “use this Group” or “none of these” — rather than blocking.
  5. Runs before the carrier check, so nobody fills in an authorisation for a location that already exists.
Front door

① Self-serve signup

Cheap, and billing accuracy depends on it — duplicates make the Group count disagree with the invoice.

Moves with
Open questions
  • Is an exact number match a hard block, or should an operator be able to override it on the on-behalf path?

Kyle

Design space

To design

The registry card below in all three states — clear, near match, exact match with the routing hand-off. It sits above the carrier check because finding a duplicate should cost one field, not twelve.

Nothing to evaluate yetNot a September decision — the design space stays empty until it is.
Brand enablement · ref B1
C2 Effort S Front End Design

HubSpot Company ID is optional at Team creation

What it costs today

Breaks CRM and billing linkage downstream, and it is discovered late.

Proposed solution

Required-field validation at team creation

  1. The field becomes required at Team creation, with format validation.
  2. Lookup against HubSpot so the ID is verified, not merely present.
  3. Existing teams surface in a backfill list.
Front door

Team creation checklist

Bucket B is a checklist problem. This is one line of it.

Moves with
Nothing else depends on it
Open questions

Nothing outstanding — this one is ready to spec.

Design space

To design

The HubSpot Company ID field at team creation — required, format-validated, and showing a verified state once it resolves against a real company.

Nothing to evaluate yetNot a September decision — the design space stays empty until it is.
Brand enablement · ref B5
C3 Effort S Backend Design

Compliance automations aren’t seeded on new accounts

What it costs today

Start/stop compliance automations are added by hand. One-time work, but forgotten.

A button in Kiosk that could add the compliance automations.Tim, Aug 4
Proposed solution

Seed the compliance automations as a step in New Team set-up, not a button someone has to remember

  1. A Compliance step in the New Team flow seeds start/stop compliance automations on the team as it is created.
  2. Idempotent, so re-running it is safe; it shows as an unchecked item until it has actually run.
  3. Sits alongside Intelligent Inbox and the owner terms send, so all three one-time-per-brand chores happen in the same pass.
Front door

New Team set-up

Days of work. Removes a recurring one-time-per-brand chore.

Moves with
Nothing else depends on it
Open questions

Nothing outstanding — this one is ready to spec.

Design space

Team Creation

The Compliance step in New Team setup. Seeding happens at creation as part of the flow, so the automations exist before anyone could forget them — idempotent, so pressing twice is safe, and visible as unchecked until it has run.

New Team — Compliance step seeding automations at creationTeam CreationSeeded on creation — compliance automations, Intelligent Inbox and the owner terms send, each an idempotent step in the New Team flow rather than a chore to rememberOpen the prototype
Brand enablement · ref B6
C4 Effort XL Front EndBackend Design

Brand and campaign registration happen outside the skill

What it costs today

~10 rejection events across 8 customers in 12 months, and we are losing Twilio FastTrack support.

Proposed solution

Submit to TCR directly from Kiosk, with the Messaging Registration skill running inline as pre-validation — registration is per brand and one-off, so it is not blocked by the Bandwidth timeline

  1. Registration is per brand and happens once; assigning numbers is per group and happens at the aggregator. This surface ends where that begins.
  2. Step 0 is the landing view: brand identity status, vetting, every campaign, and each carrier’s decision — nothing shows this today.
  3. Three different things are called status — TCR campaign, per-carrier decision, and DCA sharing. They render as three fields, never one badge.
  4. Use-case qualification reads from TCR per brand: which carriers qualify, actual tpm, and how many samples each requires — which then configures the campaign form.
  5. The skill’s accumulated pass/fail rules run in-form before submit. That is the feature; it replaces the Twilio FastTrack safety net we are losing.
  6. Rejection categories deep-link to the field that caused them, then fix → re-share → nudge — branched by aggregator, because Bandwidth does not support the TCR nudge.
Front door

Team creation checklist

v1 is pure API reads and genuinely Lucas-shaped. It also feeds the Groups page Campaign and In campaign columns directly.

Moves with
Open questions
  • One brand per Voxie team, or can a team hold several? Drives the whole data model — Tim
  • Multiple campaigns per brand: how do teams use them today? — Kyle
  • Where do TCR API credentials live, and who can trigger a submit from Voxie? — Graham
  • Can the Messaging Registration skill be called synchronously for inline pre-validation? — Tim, Lucas
  • For Twilio-registered legacy brands, is step 0 read-only until re-registration? — Tim
  • Does v1 read-only fit the September window, and does it need a backend proxy for Basic auth? — Lucas

Lucas — September feasibility

Design space

Messaging Registration

The prototype: brand identity and vetting state, every campaign with its TCR status, DCA sharing and per-carrier decisions kept as three separate fields, the qualification table, inline pre-validation before submit, the rejection and remediation path, and the reconciliation against the Groups page Campaign column.

Messaging Registration — brand identity, vetting, and per-carrier campaign decisionsMessaging RegistrationWhere the brand actually stands — identity ladder, vetting as an unmade spend decision, and three separate kinds of status per campaign with Verizon reading “no report” rather than rejectedOpen the prototype
Brand enablement · ref B7
C5 Effort S Backend Design

Intelligent Inbox is not enabled by default

What it costs today

Adoption reads near-zero, which turns into board questions.

Proposed solution

Make AI enablement a default go-live step

  1. Intelligent Inbox enabled as a default step at go-live.
  2. Appears on the readiness check (B4) so it cannot be quietly skipped.
  3. Adoption visible per brand.
Front door

Team creation checklist

Process only. The board is already asking about adoption.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

To design

The Compliance step at team creation, where Intelligent Inbox is enabled by default rather than left as an afterthought.

Nothing to evaluate yetNot a September decision — the design space stays empty until it is.
Groups at scale · ref A8
C6 Effort S Backend Blocked

Owner role is not supported in user import — and only Owners can enter payment details

What it costs today

Gates A3 and A4 entirely, which means it gates the whole self-serve front door.

It appears to be a deliberate block… we need to ask Graham why this is not allowed.Tim, Aug 4
Proposed solution

Unblock Owner provisioning — the answer is needed before anything else is specced

  1. Answer first: why is Owner blocked in user import?
  2. If it is permissions hygiene, allow Owner on import and on self-serve creation.
  3. If it is architectural, self-serve needs a payment path that isn’t Owner-gated.
Front door

Blocks front door ①

A hand-raiser who adds a card must be an Owner. There is no way around it.

Moves with
Open questions
  • Why is the Owner role blocked in user import? Highest-leverage question on the list — and it is a Slack message.

Graham — before the onsite

Design space

To design

Nothing to draw until the answer lands. Two branches to design against: Owner-at-signup, or a delegated payment path.

The UI for C6 lands hereNot designed yet.
Groups at scale · ref A17
C7 Effort M Front EndBackend Blocked

Training is coordinated and delivered per franchisee

What it costs today

Caps how many locations can go live at once regardless of platform capability — "the real limiter on wave size."

Training doesn’t scale, and it’s the real limiter on wave size.Kyle Daniel
Proposed solution

Self-serve training signup in the same form. Delivery model goes to the CS session

  1. The franchisee picks a training slot inside the signup form.
  2. Slot capacity is visible, so wave size and training capacity become the same number.
  3. Delivery model stays with CS — product only books it.
Front door

① Self-serve signup

The cheap hedge. If training really is the cap, neither front door raises the ceiling.

Moves with
Open questions

Nothing outstanding — this one is ready to spec.

Design space

To design

Not designed yet. The artefact would be a slot picker in the signup form plus the capacity view an operator plans a wave against.

The UI for C7 lands hereNot designed yet.