Contract continuity on n8n
A public hospital finds out too late that a contract is ending. I ran the deployment end to end: discovery, a scored backlog, two live n8n workflows and the operating model the hospital keeps.
Overview
Spanish public hospitals buy most recurring services on fixed-term contracts, and nobody owns the end date. I treated it as an enterprise deployment, not a demo: a discovery on public procurement data, nine automation opportunities scored by value, readiness, effort and risk, the top two built and running on n8n Cloud, and a one-page operating model covering intake, ownership, a review gate, credentials and expansion signals. Claude drafts; a named person decides; every decision is logged.
At a glance
- 15 %of one hospital’s 255 recurring contracts need a decision nowPublic data · radar 10 Oct 2026
- 84 %of the urgent ones have no successor foundHeuristic match, precision not yet measured
- 1 emaila week to the procurement head: five briefs, one form, a required decision eachLive on n8n Cloud
- 20 → 6deserted lots grouped into tenders, each classified and routed onceLive on n8n Cloud
- 9opportunities scored; the highest-value one deliberately ranked lowBacklog
- 0buyer names in the public repo, checked by an anonymity gate before every pushMeasured
The problem
A hospital renews maintenance, supplies and services through public tenders that take months. The law leaves little slack: an extension binds the supplier only with two months’ notice, and a lapsed contract can be bridged for nine months only if the new tender was published three months before the end. The real deadline is the publication date, long before the end date.
In practice the end date lives in someone’s spreadsheet or memory. When it is missed, the hospital extends on emergency terms or keeps paying without a contract, and both come back later as audit findings.
The fix is not faster tendering. It is starting earlier, with a named owner and a dated decision.
What I built
Two workflows on n8n Cloud, fed by a read-only API over the procurement data I already maintain.
- Weekly expiry radar: fetches contracts at risk, keeps the ones needing a decision, has Claude write a short brief for each, and sends the procurement head one email with one form: Claude’s suggestion and a required decision per contract. Every answer lands in a decision log with who, when, and what Claude suggested.
- Deserted-lot triage: groups lots nobody bid for by tender, skips any already triaged, has Claude classify the likely reason with the hospital’s own rules (structural, earlier decision, addressable), routes each tender to the owner who can act, and logs it once.
- A read-only API: the system of record stays the system of record. It serves anonymised codes and tokens, never links, supplier or buyer names.
My role
I ran it the way an on-site deployment runs, with the business workstream first.
- Discovery. An as-is process map, a stakeholder map with the likely skeptic (financial control), the legal timing, week-one interview questions and four hypotheses the pilot must prove or kill. Discovery ↗
- Prioritisation and value. Nine opportunities scored as value × data readiness ÷ (effort + risk), a 90-day roadmap with a measured gate between phases, and ROI logic that leads with risk and staff time, not price. Backlog ↗
- Build. The top two opportunities as n8n workflows, generated from code so every node version and connection is reviewable, then run live on n8n Cloud with real email and data tables. Set-up guide ↗
- Governance. An operating model the hospital keeps: roles, intake, a RACI, a nine-point review gate, a credentials policy, run metrics and the expansion signals to hand to Customer Success. Operating model ↗
Key design decisions
Where the judgement is.
A person decides every item.
Claude drafts and suggests; the procurement head chooses from four options. Nothing is sent to suppliers. If nobody answers in three days, the run logs “no answer”, so silence is visible.
One email a week, not one per contract.
Five decisions in one form respects the head’s time, which is what decides whether the workflow is used at all.
The highest value ranks low on purpose.
Drafting tender documents with AI has the most value and the most risk. It waits until simpler workflows have earned trust with legal and financial control.
Unreadable is never dropped.
When Claude’s reply can’t be read, the item becomes a low-confidence case routed to a person, not a crash or a silent gap.
Never twice.
The triage checks its own log before working, so running it again sends nothing and logs nothing new.
Anonymous by construction.
Hospital codes and contract tokens are keyed hashes, titles are scrubbed against a private list, and a gate scans every tracked file before a push.
What the live runs found
Each run, a fix.
None of these showed up in planning. Each one changed the workflow.
Fetch
Found
The public snapshot is served as plain text, so n8n read 38 contracts as one string and stopped silently.
Changed
The request forces JSON parsing; the dry run now uses the same URL as production.
Format
Found
Claude wrapped its JSON in a code fence and an extra layer; the strict parser failed two of five briefs.
Changed
A tolerant parser, and a visible fallback for anything still unreadable.
The heuristic
Found
The matcher paired a donor-semen contract with an oocyte contract as its “successor”. Claude’s brief pointed out the mismatch.
Changed
Kept as the design: the heuristic proposes, Claude checks, a person decides, the log records all three.
Grouping
Found
One tender had 13 deserted lots, so the first triage wrote the same brief six times.
Changed
Lots are grouped by tender before triage: 20 lots became 6 different cases.
Quotes
Found
One reply broke JSON with a quote inside a value; that tender went to a person as “unclear”.
Changed
The safety net worked; the parser now also reads the fields one by one.
Live on n8n Cloud
Decisions in these screenshots are illustrative demo answers, not a hospital’s.
What the pilot must prove
| H1 · Procurement answers the weekly digest: items answered within 3 days | ≥ 80 % |
|---|---|
| H2 · The radar is right often enough to trust: matcher precision on the first 50 answers | ≥ 70 % |
| H3 · Earlier decisions mean fewer lapses: lapses per quarter against the baseline | Falling |
| H4 · Claude helps rather than biases: override rate, with reasons logged | 10–50 % |
Tech stack
- n8n Cloud
- Claude (Sonnet, via n8n)
- Gmail send-and-wait forms
- n8n Data tables
- Switch and Merge routing
- Python (stdlib HTTP server)
- DuckDB
- Keyed-hash anonymisation
- Public PLACSP data
What I’d do next
- Feed every form answer back into the matcher as ground truth, so precision is measured, not assumed.
- Extension-notice alerts three weeks before the two-month deadline, the next item on the backlog.
- A monthly sponsor report built from the decision log.
- Move the digest from a personal mailbox to a shared procurement one, as the credentials policy requires.
Independent project on public PLACSP procurement data. No hospital, buyer, region or tribunal is named; the hospital appears as an anonymous code and was a design partner of independent research, not a customer. Decisions shown are illustrative. n8n and Claude are the tools used; this project is not endorsed or sponsored by n8n or Anthropic.
Next projectLicita