Make one strong routine usable by other people.

Capacity / Department of 10

Make one strong routine usable by other people.

The wider gain comes from shared inputs, connected tools, training and checks. Test whether a good routine transfers before extending it across the department.

An experienced user’s routine becomes shared inputs, a small pilot, training and a checked departmental workflow. — Illustrative reconstruction of the work. The picture does not establish a result.

Capture the routine
Keep the inputs, template, handoff and review points.
Pilot and teach
Try it with three people, check quality and fix what does not transfer.
Shared support
A common data and AI setup supports the team; individual gains still vary.

Same accepted work. Review and upkeep included.

Before200 staff-hours

With the routine160 staff-hours

40 staff-hours released on the same batch200 ÷ 160 = 1.25× output per hour (+25%). Time reduction and productivity increase are different measures.

Hypothetical batch, not a whole workweek, a payroll cut or a forecast. Accepted quality must remain comparable.

Open the detail

Keep the setup, assumptions and checks in view.

How one reusable workflow can raise a whole department

A department does not improve because everyone becomes an expert overnight. It improves when a proven routine becomes easy for other people to use reliably.

See what changes

Starts: With one strong user’s real proposal routine.
Becomes: Shared approved inputs, a template, training and checks.
Takes: More investment than one person, and people improve unevenly.

Ten people, two rows of five, connected through shared data.

Hypothetical rollout · a standard sales-proposal routine in a department of ten

Strong user Capture one strong routine
An experienced salesperson’s proposal process is written down: inputs, checks, template, handoff and review points.

1 of 10 using it
Shared inputs Adapt it into shared inputs
The department uses approved pricing, scope fields, examples, language and required quality checks.

1 of 10 using it
Three pilot users Run a small pilot
Test on a limited number of proposals. Measure preparation time, corrections, completion and adoption.

3 of 10 using it
Managers Train and check
Show people how to use the routine. Managers review quality and reinforce the steps.

3 using it, 7 in training
Whole department Expand carefully
Make it available to everyone once the pilot shows evidence. Track results by person and as a team.

Open to all 10, use varies

Back to the shared routine: when real use reveals friction, the template and checks improve for everyone.

The same proposal on an ordinary day

Hypothetical workflow · one salesperson who is not the expert

Before: everyone works from their own version

Salesperson Find the latest version
Look for current pricing, a good past proposal and the customer’s notes.
Salesperson Build it their own way
Structure, wording and checks can differ from person to person.
Salesperson and manager Review, send and update
Quality depends on who wrote it and who checks it. The record is updated by hand.
Salesperson What was learned
Stays with the person who learned it.

After: one shared routine, with a named owner on every proposal

Recurring schedule List the day’s work
A scheduled check lists new requests, follow-ups and missing details, each with an assigned owner.
Assistance Draft from shared inputs
The assistant prepares a ready-to-check pack from approved pricing, scope fields, examples and the template.
Human check Owner checks and approves
The assigned owner confirms prices, scope, customer fit and wording. A manager handles anything unusual.
Execution Record the approved result
With the needed integration and permissions, the workflow files it and updates the shared record.
Recurring review Improve it for everyone
On a set schedule, corrections and misses are reviewed, then the shared template and checks are updated.

40 hours saved in total and +25% productivity: how the same work gives bothWorked example, with review and upkeep included

Staff-hours for the same batch of work, all ten peopleScale: 0 to 200 staff-hours

Today200 h
After rollout160 h

40 staff-hours released. The striped section is the time back.

Output per staff-hour on that workScale: 0 to 1.5x today’s rate, the same scale as the one-person example

Today1.0x
After rollout1.25x

200 ÷ 160 = 1.25x, or +25%.

The same change reads two ways. The batch takes 20% less time, and each staff-hour produces 25% more. Those are different measures of one change, so 20% and 25% are not interchangeable.

This assumes comparable accepted work. The 40 hours are a department total on one batch of work. They are not a 40-hour workweek, a payroll cut, a whole-company result or a proven outcome.

The same 40 hours, but not 4 hours each

One assumed spread of hours released per week, per personScale: 0 to 12 hours. Assumed, not measured.

Strong user12 h
Person 28 h
Person 35 h
Person 44 h
Person 53 h
Person 63 h
Person 72 h
Person 82 h
Person 91 h
Person 100 h

Total: 40 hours. 12 + 8 + 5 + 4 + 3 + 3 + 2 + 2 + 1 + 0

Do not expect equal gains. One person may go well beyond the others. Several may gain a useful amount. Someone may not be using it yet.

The strong user’s value can spread. Their routine helps others only once other people can use it reliably, through shared inputs, training and checks.

Measure both levels. Track results by person and as a team, because a team total can hide who still needs help.

Your department’s spread will look different. This one only shows that 40 hours need not be shared evenly.

What the department has to build that one person doesn’t

Test it with a small pilot

The routine: Standard proposals, from new request to approved draft.
Who tries it: Three people: the strong user and two others, so you can see how well it transfers.
Input you can check: Manager-approved pricing, scope fields, example proposals and the template.
Output you can check: A pack listing its sources, and a logged approval from the assigned owner.
What to measure: By person and as a team: preparation time per accepted proposal, corrections, completion and whether people keep using it.
What happens next: Fix what the pilot revealed. The other seven join once the evidence supports it.

Three different results

Hours releasedTime back across the team on the same work.
More accepted outputDepends on useful redeployment, demand and accepted quality.
Financial returnAlso depends on delivered work and total costs, including the shared setup. Collected cash is a separate check.

What if one person becomes a standout?A possibility to think about, not a rate

With the right shared setup, an exceptional user can go far beyond the rest and help pull others up. In one hypothetical example, a team of twenty has one standout and some colleagues reach about 2x on work they have adapted.

Treat that as an assumption to test, not an established rate or a forecast. A department of ten may have no standout at all. The +25% example does not rely on it: it does not assume that everyone doubles, that everyone adopts equally or that any share of people becomes exceptional.

What published research shows about uneven gainsOne large study, in customer support rather than proposals

Among 5,172 support agents, AI assistance raised issues resolved per hour by 15% on average, with varied effects. Less experienced and lower-skilled agents gained more. The highest-skilled gained little speed, with a small quality decline. This fits the shared-practice idea in a narrow setting. It does not prove proposal or company results.

Source: Brynjolfsson, Li and Raymond, “Generative AI at Work,” Quarterly Journal of Economics, 2025.

Worked department setup, stack and costsHow a proposal moves, the stack, people and checks, monthly cost and sources

Overview

A department takes more coordination, but can create more total capacity. Equipping ten people takes more than giving everyone the same tool. It can take shared data, connected systems, team training, agreed ways of working and quality checks, and all of that takes more time and budget.

In this illustrative example, the department saves 40 hours a week in total and shows a 25% productivity increase. The percentage is smaller than the individual example, and the total capacity is larger. Neither figure assumes a 40-hour workweek, a payroll reduction or a specific financial return.

Example values for a department of 10 after rollout, preparing standard sales proposals on company accounts. Three people pilot it first. An assigned owner approves every proposal.

Hypothetical example · same weekly workload

200 staff-hoursToday
160 staff-hoursWith the setup
40 hBack each week across the team

The full department after rollout completes its usual batch of work in fewer hours, with review and upkeep included.

How one proposal moves

Deal in HubSpotStage and owner set
Shared approved contextTemplates, pricing and examples from Drive
Postgres queueProposal tracked by ID with an assigned owner
Agent preparesGrok Bot drafts the proposal and evidence pack
ChecksClaude review against approved examples
Person approvesAssigned owner or manager signs off
RecordedHubSpot status and run log updated

The stack

Records: HubSpot is the source of record, Supabase Postgres tracks the queue, Google Workspace holds approved docs
Agents: Grok Bot Teams seats on company accounts
Builders: Codex through ChatGPT Business, in VS Code and a repo
Reviewers: Claude Team for results and playbooks

One deal, start to finish

A deal in HubSpot reaches the proposal stage and a work item enters the queue with an assigned owner.
The queue service gathers the deal record, the shared approved template, pricing and examples.
Grok Bot prepares a proposal draft and an evidence pack that lists the sources used.
The owner hands the draft and evidence to Claude for a check against approved examples, then checks facts, scope, pricing and exceptions. A manager handles anything unusual.
The owner approves and sends. The approval is logged and the status goes back to HubSpot.

People and checks

Team trainingThree pilot operators learn the routine first. All ten join only after the pilot shows evidence.
Quality checksEvery draft gets a human check before it goes out. Managers approve templates and exceptions.

The service delivers the working setup. BH Technology maps the workflow, cleans the source data, sets permissions per identity, builds the queue service, tests it in the pilot and trains the team. Each part is scoped and quoted separately.

Example monthly subtotal for licenses and the database is $545 (10 Grok Bot seats, 3 Codex through ChatGPT Business, 3 Claude Team, Supabase Pro). With new Google Workspace it is $713. Usage, CRM, hosting and the setup service are separate costs.

USD before tax. Sources xAI Teams, ChatGPT, Supabase.

Go deeper

Shared data

Can everyone see the same customer or work situation? Yes, when one record brings the facts together and each source has a named keeper.

One work recordFictitious deal · Sample Co renewal

Record IDhubspot deal 48213HubSpot
One reliable identifier. One deal ID gets one open work item, so a duplicate run cannot quietly create a second job. Without a stable ID, people and tools can work the same deal twice.
Ownerrep_cHubSpot
The person responsible for movement. HubSpot owns customer status, deal stage and owner. If this field is blank, a stalled deal has nobody to ask.
StatusProposal sent, no reply after 3 business daysHubSpot
Where the deal stands. The trigger here is the silence: no reply after 3 business days. If status is out of date, the next step gets prepared for the wrong situation.
Next actionFollow-up draft and next task, for rep_c to checkWork queue
A Postgres queue item for deal 48213 is assigned to rep_c, and Grok Bot prepares the draft and next task. In the sample, rep_c checks facts, tone, pricing and exceptions, corrects one price line and approves on Nov 4 at 09:12. Run 0917 shows no error, and the final status and note file back to HubSpot.
Company contextfollowup-playbook v4, pricing-2026-11Drive
The rules and definitions around the record. Old pricing or empty notes block the draft, so the routine stops instead of guessing. The queue row stores only a link and status. Customer details stay in HubSpot.

Who keeps it true

HubSpot: system of recordNamed deal owner
Owns customer status, deal stage and owner. Reps see their own accounts, and final status and notes return here after approved work.
Drive: approved docsSales manager, reviewed monthly
Holds two approved context docs, followup-playbook v4 and pricing-2026-11. The sales manager owns and reviews both each month.
Postgres: work queueBuilders maintain the service
Tracks work state, approvals and runs by ID. In the department example, 3 builders maintain and test the queue service, and the company owns it.

Shared data means the right accessWho can reach what

Reps see approved context and their own accounts.
Managers approve templates and exceptions.
With row-level security policies configured, each identity reaches only its assigned work.
Agent tools hold only scoped keys.

How the work item moves

New
Preparing
Needs review
Approved
Filed

Any item that fails a check moves to Exception for a manager.

The three data layers, one queue row and the full sample dealStored fields, deal timeline, permissions and sources

Shared data

Three layers

HubSpotSystem of record
DriveApproved docs
PostgresWork queue

HubSpot: Owns customer status, deal stage and owner.
Drive: Holds two approved context docs, followup-playbook v4 and pricing-2026-11. Sales manager owns and reviews both monthly.
Supabase Postgres: Tracks work state, approvals and runs by ID.

What one queue row stores

Link · hubspot deal 48213
Context · playbook v4
State · approved
Approved by · rep_c · Nov 4 09:12
Run · 0917 · error none

Customer details stay in HubSpot. The row holds a link and status only.

One sample deal, start to finish

Fictitious deal and names for illustration.

Where the deal livesHubSpot deal 48213 · Sample Co renewal · stage Proposal sent · owner rep_c · no reply after 3 business days
Approved contextfollowup-playbook v4 and pricing-2026-11 in Drive · owner sales manager · reviewed monthly
AssignmentPostgres queue item for deal 48213 assigned to rep_c · Grok Bot prepares the draft and next task
Approvalrep_c checks facts, tone, pricing and exceptions · approved Nov 4 09:12 · one price line corrected
Run traceRun 0917 · error none · final status and note filed back to HubSpot

New
Preparing
Needs review
Approved
Filed

Any item that fails a check moves to Exception for a manager.

Shared data means the right access. People and agents reach only the approved records their job needs, and every important action has an owner and a review trail.

Permissions

Reps see approved context and their own accounts.
Managers approve templates and exceptions.
With row-level security policies configured, each identity reaches only its assigned work.
Each item carries the minimum fields the job needs.
Agent tools hold only scoped keys.

Connected tools

What makes a connected workflow different from owning several tools? Work crosses a real permission line, a named person approves, and each step leaves a log.

Example service · the company builds and owns this queue

Bot zone · restricted access

1QueueReads approved fields and removes duplicates
The service reads approved HubSpot fields and removes duplicates by stable deal ID. It holds the work. It does not decide what is correct.
In this example, 3 builders use Codex through ChatGPT Business to maintain and test the service.
Bot zone · assigned work only

2Prepared packA draft and next task for one assignee
Each bot gets only its assigned work through a restricted app or export. Across 10 Grok Bot Teams seats, the lead gets a morning brief, reps draft follow-ups from their queue and operations gets handoff notes.
Limit to know: app permissions sit on each member’s identity, so bots under one member share that member’s access.
Approval line · own login

3Person checks and approvesNothing goes out without this step
The assigned person checks the pack and approves it, corrects it or rejects it. There are no shared logins and no blanket auto-send.
In this example, 3 reviewers using Claude Team check results and update playbooks, so a correction can improve the next run.
Record · logged

4Logged record updateDraft and approval logged separately
Separate draft and approval entries show what was prepared and who accepted it. For example, a reviewed proposal can trigger an approved record update and create the next follow-up task.
The records in this example are HubSpot, Google Workspace and Supabase Postgres.

When it does not go to plan

Fails a checkMoves to Exception for a manager
The item leaves the normal path, and a manager decides. Managers also approve templates, so a repeated exception has an owner who can change the template.
Permission failureThe run stops and is logged
It never borrows wider access. ChatGPT Business and Claude Team logins stay with their users, and bots get only the restricted app access.
Integration failsWork falls back to manual
The queue keeps moving by hand until the connection is fixed. That only works if people have been trained on the manual path.

The test: software alone is not a team workflow. Without permission, logging and ownership, it is only moving information around. Enterprise-only controls are not assumed here.

The company stack and the example serviceSeats, roles, ground rules and product sources

Connected tools

The company stack

Grok BotRuns jobs
QueueHolds work
PeopleApprove
HubSpotRecords

Grok Bot Teams: 10 company seats. The lead gets a morning brief, reps draft follow-ups from their queue, operations gets handoff notes.
ChatGPT Business: 3 builders use Codex to maintain and test the queue service.
Claude Team: 3 reviewers check results and update playbooks.
Records: HubSpot, Google Workspace and Supabase Postgres.
Code: VS Code and a shared repo.

Ground rules

One example service

ReadsApproved HubSpot fields
ChecksRemoves duplicates by stable deal ID
AssignsGives each bot only its assigned work through a restricted app or export
RecordsDraft and approval logged separately

The company builds and owns this queue service.

App permissions sit on each member's identity. Bots under one member share that member's access.
ChatGPT Business and Claude Team logins stay with their users. Bots get only the restricted app access.
No shared logins and no blanket auto-send.
If the integration fails, work falls back to manual.
Enterprise-only controls are not assumed.

Team training

How does one strong user become a repeatable team practice? Three people test it on real work. More people join only after the evidence passes.

Sample path to ten · each dot is one person, not a measure of use

Before the pilot: prepare the groundBaseline, data and context, access, historical tests

Time the current baseline.
Tidy data and write approved context.
Set role-based access.
Test on historical cases in isolation, so mistakes reach no customer.

Pilot: 3 people in total1 strong user + 2 others · draft-only · four weeks
The total is three, including the strong user. Everyone stays draft-only, so a person approves all output while the routine is being proven.
Why two others: if the routine only works for the person who built it, it is not ready to share. Do not assume equal adoption.

Coach from real workCorrections become the lesson
Train each role on review and exceptions using the pilot’s actual drafts: what was corrected, why, and when an item should have gone to an exception. Each role learns what it checks, rather than how the tool works in general.
Evidence gateChecked before each phase
- Same accepted quality
  Compared with the baseline. Faster work that gets accepted less often is not a pass.
- Staff minutes measured
  Active minutes are measured, not estimated, so the gate rests on the same work and real timings.
- Exceptions trending down
  If exceptions are not falling, more people would inherit the same problem. Fix the routine or its inputs first.
- Named owner signs off
  One named rollout owner is accountable for the decision to widen, so the decision is never left to enthusiasm.
Rollout: in phases to all tenOnly when evidence supports the next phase
The outlined dots are the seven people the rollout still has to reach. The sample plan does not fix phase sizes, and the gate repeats before each one.
Being included in the rollout is not the same as using the routine well. Keep checking real work, because people improve unevenly. The sample plan allows 15–30 h for training, as a planning figure only.

The seven-step path to ten and the phase gateOriginal rollout order and training planning figure

Team training

Path to ten

Pilot3 people
EvidenceGate passed
Rollout10 people

Time the current baseline.
Tidy data and write approved context.
Set role-based access.
Test on historical cases in isolation.
Run a three-person draft-only pilot for four weeks.
Train each role on review and exceptions.
Roll out in phases to all ten.

Gate before each phase

Same accepted quality as the baseline.
Active staff minutes measured, not estimated.
Exceptions trending down.
A named rollout owner signs off.

Training runs 15–30 h in the sample plan. Planning figures only.

Quality checks

Where should human judgment stay in an AI-supported routine? At the gates a polished draft can still fail. Quality means accepted work with fewer avoidable errors.

One draft, five gates · each gate shows what happens if it fails

1InputsAre the records current and complete?If not: draft blocked
Old pricing or empty notes block the draft. One deal ID gets one open work item, so a duplicate run does not start a second one.
2Scope and pricingDo the terms match the approved source?If not: corrected first
Sends, pricing and unusual terms all need human approval. In the fictitious sample deal, the rep corrects one price line before approving.
3TemplateIs the correct version being used?If not: back to current version
Managers approve templates. Prompts, context, schemas and scripts are versioned, so the team can tell which version a run used and restore a safe one.
4ExceptionsDoes this case need escalation?If yes: goes to a manager
Any item that fails a check moves to Exception for a manager. A permission failure stops the run and logs it. It never borrows wider access.
5Human approvalHas the authorized person accepted it?If not: nothing goes out
A run log for every job records its source, reviewer and error, so approval can be checked later. The draft sounding good is not the test.

Back to gate 1: learn from reworkFix the source, not only the draft

For example: a proposal draft looks polished but uses an outdated delivery assumption. The reviewer catches it, corrects the source and records the issue so it does not repeat.

When something breaks

DetectMonitor flags it
Failures and exceptions are monitored daily, using the run log.
PauseAgent stops
Stopping first keeps one fault from reaching more work.
RestoreLast safe version
This is why prompts, context, schemas and scripts are versioned.
ManualPeople handle the queue
The manual fallback is documented and trained, so the work continues while the fault is fixed.

Failure recovery, common failures and all checksThe original recovery path and control list

Quality checks

When something breaks

DetectMonitor flags it
PauseAgent stops
RestoreLast safe version
ManualQueue handled by people

Common failures

Stale or missing: Old pricing or empty notes block the draft.
Duplicate runs: One deal ID gets one open work item.
Permission failure: The run stops and is logged. It never borrows wider access.

Checks

Human approval for sends, pricing and unusual terms.
A run log for every job with source, reviewer and error.
Daily monitoring of failures and exceptions.
Prompts, context, schemas and scripts are versioned for restore.
Manual fallback is documented and trained.

More time and budget

What does it cost to make a routine reliable? Some costs happen once and others return every month. Neither one tells you the return.

Sample plan for ten users · blocks show when a cost occurs, not how large it is

Once, to make it work120–240 h of service work

SetupDiscovery, data and context, tests and pilot
Discovery 20–40 h, data and context 30–60 h, and tests and pilot 25–50 h. This is the work of finding the routine and making its inputs fit to use.
IntegrationPermissions and connections
Permissions and integrations take 30–60 h. This is the part that makes tools act as one workflow, with access limited to what each job needs.
TrainingTeaching each role and rolling out
Training and rollout take 15–30 h. That covers training people to review, handle exceptions and use the routine in real work.

Every month, to keep it workingContinues for as long as the routine runs

Month 1
Month 2
Month 3
And on

LicensesSeats and platform plans
Sample software is $545 a month before Workspace, or $713 with new Google Workspace. It covers Grok Bot seats, 3 ChatGPT Business builders, 3 Claude Team reviewers and Supabase from $25. USD before tax, checked Nov 4, 2026.
Usage and other extrasNot in the sample total
CRM, usage, hosting and extra environments are extra. They depend on your systems and how much work runs, so ask for them separately in any estimate.
UpkeepSupport work, 12–24 h a month
Monitoring access, fixing failed runs and applying tool updates. A routine that releases staff time can still need this work every month.

Where the 120–240 setup hours goPlanning ranges on one hours scale

Planning range per phase · scale: 0 to 60 hours

Discovery20–40 h
Data and context30–60 h
Permissions and integrations30–60 h
Tests and pilot25–50 h
Training and rollout15–30 h

At a hypothetical $150 an hour, used only as a planning example, setup comes to $18,000–$36,000 and support to $1,800–$3,600 a month. BH Technology scopes and quotes each client separately.

Cost is not return. Lower labor time does not automatically equal ROI. Judge the build by actual margin gained compared with the total cost of software, setup and support.

Complete software and service cost tablesPer-seat prices, full totals, the all-ten comparison and pricing sources

More time and budget

Monthly software, 10 users

Illustrative planning prices in USD a month before tax, checked Nov 4, 2026. Plans, terms, usage and regional pricing change, so check current plans before relying on them.

Grok Bot seats: 1 Super × $100 + 9 Premium × $30 = $370
ChatGPT Business: 3 builders × $25 = $75
Claude Team Standard: 3 reviewers × $25 = $75
Supabase Pro: From $25
New Google Workspace: $16.80 × 10 = $168, total $713

$370 + $75 + $75 + $25 = $545 a month before Workspace. All ten on Codex and Claude would start at $895 before Workspace. CRM, usage, hosting and extra environments are extra.

Service work at a hypothetical $150 an hour

Setup 120–240 h: Discovery 20–40 h, data and context 30–60 h, permissions and integrations 30–60 h, tests and pilot 25–50 h, training and rollout 15–30 h. Total $18,000–$36,000.
Support 12–24 h a month: Monitoring access, fixing failed runs and applying tool updates. Total $1,800–$3,600 a month.

BH Technology scopes and quotes each client separately. The $150 rate is a planning example. Judge the build by actual margin gained compared with total cost of software, setup and support.