Home · Solutions · Management & planning
Solution · Management & planningOne register of what is due, when, and with whom, rebuilt every night
No case reaches its statutory deadline unnoticed
Open cases are read every night, their deadlines calculated from your own rules, and owners warned in Microsoft Teams before the date passes; people still decide and sign.
Executive summary
Deadlines live in the case system, a departmental spreadsheet and somebody's memory.
We build one deadline register for the whole office and nothing else.
Every open case carries a due date the whole office can see, calculated the same way in every department.
the deadline register in Microsoft SharePoint; notice drafts filed to the case; Power BI
Business problem
Case management
Every case carries a clock. It starts on a date the correspondence register already holds, runs for a period set by the type of case, and pauses on events recorded elsewhere. The office knows all three facts and has nowhere they meet, so a due date exists only when somebody works it out.
Habit fills the gap. Each department keeps its own list, copied from a system that keeps moving afterwards. A case waiting on a party or on another authority drops out of every list at once, because a workbook does not know it is waiting. Before a management meeting the office manager asks eleven departments where their oldest cases stand.
Nothing collapses at scale, which is the difficulty. A few cases pass their date each month, each for a defensible reason, and each surfaces only when the party writes again. The fairness cost is the one an office minds most: the party who telephones weekly gets the case that moves.
How it works today
This is the routine we find in most offices, whatever case system sits underneath.
- PersonA case is registered and assigned, and its deadline goes into the department's workbook, or does not
- SystemThe case system holds the date of receipt and the type; the period that applies lives with the person handling it
- PersonEach Friday the head of department rebuilds the list from the case system and last week's version
- WaitingCases waiting on a party, an expert or another authority drop out of view until somebody remembers them
- Risk of errorA case that will miss its date is noticed on the date itself, so the notice to the party goes out late
- Risk of errorA complaint about inaction is often the first signal that a case stopped moving weeks earlier
Why the current process costs more than it appears
The bill that never reaches the budget.
- Rebuilding a list is not the same as reading one, and this office pays for that picture eleven times over.
- Notices written on the last possible day cost more than notices written early: the party has already concluded the office is silent.
- Deadline knowledge sits with individuals rather than with the office, so a department covering two weeks of leave inherits the files but not the dates. Nothing accumulates as evidence either: when an appeal asks why a case took so long, the answer is reconstructed from mailboxes.
Cost of inaction
A deadline missed by four days looks, from inside the office, exactly like a deadline that was met. Nobody is idle, every case has a reason, and the workbooks say the department is coping. That is what keeps the process in place: no bad month, only a slow accumulation of quietly late cases.
The exposure with a date on it arrives later. A complaint about inaction or an inspection asks the office to show what was due, when it changed and what the party was told. From eleven workbooks that costs a week of the wrong people's time; from the register it is a query.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A district office of about 240 staff in eleven departments, with four subordinate units, a case system holding the correspondence register and the case files, and Microsoft 365.
About 2,100 cases open at any moment across roughly 40 case types, each with its own period and its own events that pause it.
Deadlines are tracked in departmental workbooks rebuilt weekly and in the memory of whoever handles each type.
About twelve minutes a week per open case go into checking, chasing and rebuilding lists, spread across the owner, the head of department and the office manager.
Robots read every open case each night, apply the office's rule table for each type, and maintain one register of what is due, when and with whom. Owners get a card in Microsoft Teams at the agreed horizons, the office manager Monday's breach list.
A due date exists for every case from the day it is registered, and notices are signed days ahead rather than on the date. The figures are arithmetic on assumptions, not a measurement.
Proposed solution
We build one deadline register for the whole office and nothing else. Each night a robot reads the open cases from the case system and the correspondence register: reference, type, department, owner, date of receipt and steps. It applies a rule table the office owns: which date starts each clock, which events pause it, what horizon the office works to. Out comes one row per case with a due date, a state and its reason.
The register is read in three shapes. The owner gets a card in Microsoft Teams at each horizon with the days remaining, the last recorded step and one choice: confirm the case will be finished, record what it is waiting on, or ask for the notice of delay. Heads of department get the weekly view, the office manager Monday's breach list. The notice is only ever a draft, signed by a person. No AI is used: every step is a date calculation, a rule lookup or a template merge, which the office can explain to an auditor and change itself.
UiPath Orchestrator time triggers, queues and audit log; UiPath Integration Service connectors for Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Action Center actionable notifications completed inside Microsoft Teams; Microsoft SharePoint lists; Power BI
The nightly read, the rule table and its calculation, the register and its history, the horizon cards and their escalation, the notice drafted from your template, the weekly view and the breach list
The read-only connection to your case system and correspondence register, built against the interfaces they publish
How the automated process works
- AutomationEach night a robot reads every open case: reference, type, department, owner, date of receipt and recorded steps
- AutomationThe rule table is applied case by case, and one register row is written with a due date, a state and its reason
- PersonAt each horizon the owner answers a card in Microsoft Teams: the case will be finished, it is waiting on something, or the notice is needed
- AutomationA requested notice is filled from the office's template with the case data and the chosen reason, and filed as a draft
- PersonThe owner or the head of department corrects the draft, signs it and dispatches it, the only way it leaves
- AutomationUnanswered cards escalate to the head of department, and on Monday the weekly view and the breach list reach their Teams channels
Human-in-the-loop model
Automation handles
- Reading every open case each night and calculating its due date from the office's rules
- Keeping one register with each case's state, its reason and every recalculation
- Warning the owner at each horizon, escalating unanswered cards, drafting the notice
People decide
- Whether a case can be finished on time and why not; a robot counts days, it does not judge a case
- The content of the notice to the party, who signs it and who carries responsibility for it
- The rule table, and where capacity moves when one department carries the pressure
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- open cases in the case system
- the correspondence register
- the office's catalogue of case types and rules
- steps recorded against each case
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the deadline register in Microsoft SharePoint
- notice drafts filed to the case
- Power BI
Human touchpoints: horizon cards in Microsoft Teams; the weekly departmental view; the Monday breach list
Technologies used
read open cases on a nightly time trigger, calculate due dates, queue the cards, log each run
Ahorizon cards answered inside Teams, escalated when nobody answers
Apost the weekly view and breach list, write rows and drafts to the tenant
Athe register, the notice drafts and the recalculation history
Athe weekly view by department and case type, and the trend management asks for
Asupplies reference, type, owner, dates and steps nightly
CIllustrative economic model
A model, not a promise.
Twelve minutes a week per open case buys three habits: the owner opening a file to see where it stands, the head of department rebuilding a list on Friday, and the office manager assembling a picture for management. Across an average month of 4.33 weeks that is 52 minutes per case, and €21 is a fully loaded hourly cost of an administrative post. No office was timed for any of this, and the arithmetic shows capacity returned to the departments, not a saving.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Every open case carries a due date the whole office can see, calculated the same way in every department
- Notices to parties are drafted days before a date rather than on it, from a template already filled in
- Heads of department manage a queue that arrives with dates instead of rebuilding a list every Friday
- A quiet case is warned about on the same horizon as one whose party telephones weekly, which is equal treatment in practice
The management view
- Deadline pressure stops being a monthly surprise: on Monday the office manager knows which cases will pass their date and who holds them
- Capacity is moved on evidence rather than on volume of complaint, because load is visible by department, case type and owner
- Every state a case passed through is kept with the night it changed, and the process survives leave and turnover, because no deadline lives in one memory
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- The robot signs in with its own account and reads. It cannot change a case, close one or dispatch anything; it writes register rows and drafts for a person to sign.
- Every recalculation is kept with the inputs it used, so the register shows not only that a case was due but why it thought so earlier
- Register, drafts and reports stay in the authority's own Microsoft 365 tenant, and the robots run from the EU region of UiPath Automation Cloud
- The rule table is versioned, and changes are made by the office and readable by the legal unit without asking us
Why now
The intake side has already changed. The Ministry of Digital Affairs put e-Doręczenia past 100 million items on 5 August 2026, more than 50 million of them that year. Correspondence arriving faster starts clocks faster, and the deadline side has not been rebuilt to match.
Adding people is the slow answer. NIK's audit of human-resources management in public administration (report DLO.430.2.2026, covering 2021 to 2024) found 1,212 recruitment proceedings, of which 812, or 67%, ended in an employment.
The technical parts are ordinary. Orchestrator runs work on a time trigger, an Action Center task is answered inside Microsoft Teams, and EZD RP, which NASK maintains for the Minister of Digital Affairs, offers an API.
Relevant executive roles
Deadline pressure arrives as a Monday list instead of a complaint
The Friday rebuild disappears and the queue arrives with dates against it
Complaints about inaction are answered from a record of what was due and when
Common questions and objections
No. It calculates a date from rules your office wrote, shows the owner what is missing, and drafts a letter on request. Who signs it, and whether the case can be finished, stays with people.
That is why the rule table is the first thing we build with you, and why it belongs to your legal unit. Types whose rules cannot yet be written down stay out of the register, visibly.
Most are not, which is why we check in the first week. Where it publishes an interface we use it read-only, where it publishes an export we schedule that, otherwise we agree the smallest reliable extract with your supplier.
When this is not the right solution
- Offices with a few hundred cases in two or three departments, where one shared list costs less than an integration
- Offices where the date of receipt or the case type is not recorded reliably, because the register inherits every gap
- Offices wanting one procedure automated end to end, from request to signed answer: different work
A question for the next management meeting
If a case in this office passed its deadline last month, how many days went by before anyone noticed, and did the party hear from us before that day or after it?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- A read of one month of your open cases: types, dates of receipt, steps and where deadline knowledge lives
- The deadline rule table, written with your legal unit and heads of department, and owned by you afterwards
- The nightly read, the register with its history, and the horizon cards in Microsoft Teams
- The notice of delay drafted from your template, the weekly view and the Monday breach list
We need from you
- One month of open-case data with case types, dates of receipt and recorded steps
- A named owner for the deadline rules, normally the legal unit or the secretary, and two piloting departments
- A read-only technical account for the case system, your notice template, and where the horizons sit
Stages
Discovery
One month of open cases read with the heads of department: types, clocks and what pauses them
Design
The rule table, the register, the horizons, the escalation path, the security model
Build
The nightly read, the calculation, the Teams cards, the notice draft, the reporting
Go-live
A parallel run against the workbooks, then two departments live under supervision and the rest behind them
Departmental. Effort is driven by how many case types need a written rule, whether the case system exposes open cases through an interface, and how consistently dates are recorded today.
Deadlines are arithmetic. Only the reason for a delay needs a person.
Send us one month of open-case data: case types, dates of receipt and the department holding each. You get back the share whose due date can be calculated without anyone typing it, and the types whose rules need writing down.
Calculate one month of your due datesThe neighbouring process usually has the same problem
Four intake channels, one register typed by hand, and delivery evidence filed after the fact.
View solution Customer serviceOne front door for everything a resident reportsA broken street light reported three ways becomes three separate jobs, two of them invisible.
View solution Legal & complianceInformation requests answered inside the statutory clockRequests arrive on four channels, the clock starts on all of them, and the register is written afterwards.
View solutionIndustries we deliver this in most oftenPublic sector