Which office tasks can a small, low-cost model handle?

The claim that “a small model is enough for 80% of routine office tasks” has no universal, verified basis. The share a compact model can handle reliably depends on a company’s task mix, document languages, quality requirements, and the cost of an error. Good candidates to test first include routing requests into known categories, extracting fields from consistently structured documents, and producing short summaries in a fixed format.

Set the quality threshold according to the cost of mistakes, not an arbitrary target. A wrong category on an internal email may cost a moment of attention; a wrong invoice amount can cost money and trust. This guide shows how to inventory tasks, select compact-model candidates, compare them fairly, route exceptions, and measure your own share instead of borrowing someone else’s “80%.”

Why you cannot assume 80%

Start with an inventory of actual work and its frequency. One office may handle mostly repetitive requests that are easy to classify. Another may spend half its time on unusual contracts and negotiations. An average between those businesses says little about either one.

You may not need to collect everything from scratch. Support categories, document types in accounting software, shared inbox subjects, and CRM stages already contain useful data. Export two or three months of volume and record who performs each task, how long it takes, and who catches mistakes. If only the customer notices an error, the cost is high and checks should be stricter.

Where a compact model is a candidate

Test compact models on tasks with several of these traits:

• A limited answer set: classification into 10–20 categories, language, sentiment, or priority.
• A known field schema: invoice number, date, amount, and counterparty in documents of one type.
• Short context: an email, chat message, or one-page document rather than a 150-page contract.
• Defined exceptions: a clear rule for missing fields or unknown categories.
• Verifiable output: amount must be numeric, date in range, category from an approved list.

That last case matters: some “routine tasks” do not need a model at all. If a rule can be written as a formula or condition, code is cheaper, faster, and more predictable.

Qwen3-8B, for example, is a compact model distributed under Apache 2.0. Its technical description lists support for more than 100 languages, but neither its size, licence, nor language list proves performance on your Ukrainian documents. Only a test can establish that.

Where extra checking is needed

A compact model can sound convincing and still be wrong on tasks with high error costs:

• ambiguous contracts, cross-references, or legally significant wording;
• multi-step calculations or conclusions from incomplete data;
• long documents or conversations with dependencies in different places;
• money, personal data, legal consequences, or communication with a key customer.

A compact model might locate a relevant section, while a stronger model, person, or both handle the conclusion. But an error does not always mean you need a more expensive model. First determine whether the model lacks context, in which case documents and clearer instructions may help, or whether it fails to follow rules or format, where examples and automatic checks may help. If the prompt omits the category list, a stronger model may make the same mistake.

How to compare models

A fair test needs:

• The same inputs: one set of real tasks for each model, anonymized when personal data is involved.
• Reference answers: a correct result for each example, prepared by people who know the process.
• Pinned versions: exact model name and version, test date, and settings.
• Real working language: for example, Ukrainian that includes mixed language, typos, and code-switching if they occur in practice.
• The same criteria: correct category, exact field values, and format—not which answer sounds nicer.
• A recorded prompt: identical across models, or separately tuned and documented for each.

The sample size depends on task diversity and error frequency. A few dozen examples per task class can help with initial screening. A production decision needs more, especially for rare but costly errors.

Record the type of error: wrong category, missing field, invented value, correct value in the wrong format, or refusal. Formatting errors may be fixed with instructions and rule checks. An invented value is more serious: constrain the task, add stricter validation, or send it to a stronger model. Look for recurring confusion between specific categories; the category definitions may be unclear.

Public rankings and benchmarks can help shortlist candidates, but they do not replace a test using your tasks, language, and data.

How to route exceptions

A compact model should not make every decision alone. Route a task to a stronger model or a person when a checkable signal appears:

• a rule fails, such as a non-numeric amount or an unlisted category;
• a required field is missing;
• the request falls outside known categories;
• values in the text and table conflict;
• a high-risk signal appears, such as a complaint, lawsuit, or large refund.

A model’s own confidence score is weak evidence: an incorrect answer may sound certain. Use it only alongside external checks.

For example, a model extracts an invoice number, date, amount, and supplier tax ID. Code checks that the amount is positive, the date is neither in the future nor more than a year old, the tax ID has the expected length and appears in the supplier directory, and the amount matches the purchase order. If a check fails, route the invoice to a stronger model; if the discrepancy remains, send it to accounting with the failed rule identified. Set a limit on retries and escalations so difficult cases do not circulate indefinitely.

Calculate your share

Potential coverage and the share completed successfully without escalation are different measures.

An educational task portfolio

This is an illustrative calculation, not a test result. Assume 1,000 monthly tasks: 600 request classifications, 250 invoice field extractions, and 150 complex customer replies.

If the first two classes pass predefined tests, potential coverage by a compact model is (600 + 250) ÷ 1,000 = 85%. That is not the share successfully completed: mistakes and escalations still occur within those classes.

Now assume 5% of classifications and 10% of extractions fail rule checks and go to a stronger model. Token sizes are also illustrative: classification uses 1,500 input and 50 output tokens; extraction uses 3,000 and 300; a complex reply uses 6,000 and 800. This example uses a dated snapshot of Standard rates for short context, checked on 11 October 2026: gpt-6-luna at $0.10 / $0.50 per million input/output tokens and gpt-6.1-sol at $2 / $10.

If the stronger model handled everything, the model bill would be 600 × $0.0035 + 250 × $0.009 + 150 × $0.02 = $7.35.

The compact model completes 570 + 225 = 795 tasks without escalation, or 79.5%, not 85%. The model-bill difference is less than $4 per 1,000 tasks. At this scale, the cost of undetected errors and staff time spent on escalations matter more than the token rate. Add columns for errors found after acceptance and their business cost. Cost per accepted result is total call, review, escalation, and correction costs divided by the number of correctly completed tasks.

Takeaways and first steps

The share suitable for a compact model depends on your task mix and error costs, not a universal percentage. Measure it on your own data.

1. List tasks, monthly frequency, and the cost of errors for each class.
2. Select two or three candidates with limited answers, known structure, short context, and verifiable outputs.
3. Build an anonymized test set from real examples with Ukrainian reference answers.
4. Compare models on the same inputs and criteria; record exact versions.
5. Define escalation rules and a retry limit.
6. Calculate potential coverage, actual completion without escalation, and cost per accepted result including errors.

An inventory and first test often show that the right option differs from the one you expected. BotLabs can help identify candidate tasks, estimate current processing cost, and define what to measure in a pilot.

Frequently asked questions