Colombian prestaciones laborales are not a writing problem. They are a calculation you run with the same fields every week: salary, dates, contract type, and the rules that turn those inputs into prima, cesantías, intereses, and vacaciones. An AI chat can explain the concept. Ops needs a desk-local calculator you can re-run on Monday without rewriting the prompt. That is the whole thesis. Language models are useful for vocabulary and first explanations. They are a weak surface for the work that actually closes the week: the same inputs, the same correct output, no essay required.

What prestaciones are as floor work

In Colombian RRHH, "prestaciones" is a family of obligations that sit next to payroll, not a blog topic. Prima de servicios, cesantías, intereses sobre cesantías, and vacaciones each have rules. The operator's job is narrower than the textbook: take the facts of this worker and this period, apply the rule, and leave a number someone else can audit. The hard part is not naming the concepts. The hard part is repeating the calculation without drift. Salary changes. Hire dates matter. Partial periods matter. Auxilio de transporte may or may not enter the base. Contract type changes which path you are on. The same person who asked "what is prima?" last month still has to run Tuesday's row correctly. If you treat that as a chat job, you get fluent paragraphs and fragile numbers. If you treat it as floor work, you want fields, defaults, and a total that updates when you change one input.

Why chat loses the Monday re-run

Chat is good at explanation. Ask what cesantías are, get a readable answer. Ask how vacaciones accrue, get a sketch. That helps onboarding and training. It does not finish the ops loop. The Monday re-run has a different shape:

1. Same fields as last week, with one or two values changed.
2. Exactness over polish. Close enough fails when someone reconciles against payroll.
3. Auditability. A colleague should see which inputs produced which line.
4. Speed without re-prompting. You should not invent a new conversation to change the end date.

A chat window fights that shape. You paste context, hope the model remembered the rule, and read prose looking for a number. Next week you start again. The model may invent a confident path when the contract type needed a different branch. Failure can look like success until someone else notices. That is the same split I use in what not to automate in HR ops: language jobs stay in chat; repeatable calculations with desk-local inputs belong in a tool.

Desk-local inputs beat uploaded essays

The inputs that matter live next to the operator:

• Salario (and whether auxilio de transporte applies to the base)
• Fechas (hire, period start, period end, liquidación date)
• Tipo de contrato (and the path that follows from it)
• Days worked in the period you are estimating

Those facts often sit on a machine the team already trusts, next to payroll extracts and ID lists. A useful helper takes what is in front of you and returns the estimate. It does not ask you to upload the week just to try a feature, and it does not turn salary history into a chat transcript you would rather not store. Desk-local here means the workflow stays short: open the surface, fill the fields you already know, read the total, move on. Prefer helpers that leave sensitive sheets where they already are. That preference shows up across tools.danieldiaz.dev for a reason. The blast radius of a wrong number, or of a careless paste of payroll rows into a third-party chat, is not theoretical.

What a calculator should do (and refuse)

A prestaciones calculator earns its keep when it is boring on purpose. It should:

• Expose the fields ops already uses
• Update prima, cesantías, intereses, and vacaciones when an input changes
• Show the base it used, so a human can challenge it
• Stay honest about being an estimate for a dependent worker under stated assumptions

It should refuse:

• Essay answers when a number is enough
• "Set and forget" claims across rules and edge cases you have not encoded
• Hiding the inputs behind a chat that "figured it out"
• Pretending a demo row is the same as Tuesday's queue

If the surface cannot show which salary and which dates produced the total, it is not ready for ops. If it needs a paragraph of caveats every time you change one day, it is still a conversation, not a calculator.

Soft bridge: the tool I use for this job

I keep a small surface for this exact job at tools.danieldiaz.dev/prestaciones: salary and days in, estimates for prima, cesantías with intereses, and vacaciones out. Numbers update as you adjust. No Excel. No chat thread. That tool lives on the personal workshop on purpose. Tools lives apart from ECORPA because the promises are different. Tools should stay useful and narrow. Company product carries obligations when a path breaks for someone else's hiring timeline. The bridge is soft by design. If you need a quick estimate with desk-local fields, use the calculator. If you are deciding what to automate next in talent ops, use the same filter: ship for the work a chat cannot finish with one paste. Files, batches, exact formats, desk-local sheets, and Monday calculations belong in tools. Vocabulary and first drafts belong in chat.

Founder lens without the pitch deck

I built ECORPA because affiliation and verification in Colombia are portal work, documents, returns, and judgment under incomplete data. Prestaciones sit in the same country and the same talent-ops reality, but they are a different class of problem: rules and inputs, not scavenger hunts across entities. From a founder seat in Colombian talent ops, the product judgment is the same across both. Do not wrap explanation as automation. Do not confuse a fluent answer with a closed row. Keep the human where failure would be quiet and expensive. That is human-in-the-loop as the product, applied before you buy another "HR AI" seat. This blog is not a sales pitch for ECORPA. It is a note on when a calculator is the honest interface.

A practical decision path

Use this when someone asks whether chat is "enough" for prestaciones:

• Open chat when the job is explaining vocabulary, teaching a new hire what prima is, or drafting a plain-language note a human will edit.
• Use a calculator when the job is re-running salary, dates, and contract facts into an estimate you can check.
• Demand a real product surface when third-party portals, irreversible commits, and other people's timelines are in play. Then keep judgment visible.

A useful test after the chat answer exists: what work remains? If the remaining work is "send the explanation," you did not need a tool. If the remaining work is change the end date, recompute the base, and leave a total for payroll review, the chat was only the easy part.

The one-sentence filter

Explain prestaciones in chat. Run them in a calculator. If the hard part is desk-local inputs and a Monday re-run, build or use a small surface with fields. If the hard part was "find clearer words," open the chat and save the engineering for the calculation that still hurts after the explanation is done.