On-Prem AIFree calculatorPDF, Excel, Word exportUKG Kronos Workforce Central

UKG Kronos Workforce Central AI Assistant Sizing and Value Calculator

This calculator sizes a private AI assistant for UKG Kronos Workforce Central and shows whether the value of time saved covers the GPU cost. Enter users, usage and your own throughput number; the result is GPU count, token volume, index size, hours saved and payback.

Your numbers

users

People with access to the assistant.

25 %

Share of named users who ask something on a given day.

questions
tokens

Includes retrieved passages in the prompt. 1,000 to 4,000 is common with retrieval.

items
pages
min

Be conservative; measure in the pilot.

$/h
$/month

Amortized hardware, power and hosting per GPU.

tokens/s

Aggregate throughput with batching for your model. Measure with a benchmark.

$

Your results

GPUs needed
1
Peak tokens per second divided by tokens per second per GPU, rounded up. Add one for redundancy.
Monthly value of time saved
$33,440
Daily active users
150
Questions per day
600
Tokens per day
720,000
Peak concurrent requests
1
Assumes 15% of daily questions fall in the busiest hour and about 30 tokens per second per stream.
GPU cost per month
$1,800
Index size
3.6
GB, assuming 2 chunks per page and about 6 KB per chunk for a 1024-dimension float vector plus text.
Hours saved per month
880
22 working days.
Net monthly value after GPU cost
$31,640
Payback
1.9 months
Zero means the monthly value does not cover GPU cost.

Planning estimate. Time saved is the weakest input: haircut it by 30 to 50 percent until the pilot measures it. Excludes staff, licences, networking and storage beyond the index.

Save results:

Monthly value vs GPU cost by named users

Sweeps Named users from 100 to 3000, holding your other inputs fixed.

Validate my sizing

Optional review of your inputs and a plan for measuring throughput and time saved in a pilot.

Optional. The tool and every export work without this. No spam.

How to use it

Start with named users and the share who ask something on a typical day. Set questions per active user and the tokens per question, remembering that retrieved passages count. Enter the documents to index with an average page count, then your estimate of minutes saved per question and the loaded hourly cost. Use a measured tokens-per-second figure for your model and GPU if you have one. Most load is numeric queries, not document retrieval.

  • Use realistic daily active share, often 20 to 40 percent
  • Include retrieved context in token counts
  • Measure GPU throughput on your own model
  • Haircut time saved until the pilot proves it

The formulas

Questions per day equal named users times active share times questions each. Tokens per day equal questions times tokens per question. Peak tokens per second assume 15 percent of the day's questions land in the busiest hour, so peak rate is daily tokens times 0.15 divided by 3600. GPUs equal peak rate divided by tokens per second per GPU, rounded up with a minimum of one. Index size equals documents times pages times 2 chunks times about 6 KB. Hours saved use 22 working days.

  • Peak share of 15 percent is an assumption
  • Chunks per page and bytes per chunk are assumptions
  • Throughput depends on model, quantization and batching
  • Concurrency assumes about 30 tokens per second per stream

Reading the result

If net monthly value is negative, the deployment is too small for the GPU cost or the time saved per question is too low. If payback is under 12 to 18 months with a conservative saved-time figure, a pilot is justified. Watch the chart: value grows with users while GPU cost steps up in whole GPUs, so the gap widens at scale. Timekeeping users are managers and HR, so named users are low but data sensitivity is high.

Common mistakes

The usual errors are counting every named user as a daily user, forgetting that retrieved text multiplies tokens per question, trusting a vendor throughput figure for a different model, and counting time saved on questions people would not have asked. Also remember that build effort, integration and support are real costs; the one-time build input is there so payback is not flattering.

  • All named users counted as active
  • No retrieval tokens in the prompt
  • Borrowed throughput numbers
  • Ignoring build and support cost

Frequently Asked Questions

What tokens per second should I use?

Benchmark your chosen model on your GPU with realistic prompt lengths and batching, then enter the aggregate throughput. Published figures vary widely by model size, precision and engine, so a measured number beats a default.

Why does the calculator assume a 15 percent peak hour?

Usage clusters at the start of shifts and after meetings. Fifteen percent of daily questions in the busiest hour is a common planning assumption; change the formula in your own copy if your logs show more.

Is the minutes-saved figure realistic?

Treat it as a hypothesis. Search and lookup questions often save a few minutes; complex tasks vary. Measure with a sample of tasks in the pilot and haircut the estimate before presenting payback.

Does it include staff and licence costs?

No. It covers GPU cost and a one-time build input. Add operations, storage, networking and any software licences separately for a full total cost of ownership.

We can run a measured pilot on your Kronos WFC data and replace these estimates with your own numbers. Ask for a sizing review if you want a second set of eyes.