Sales closes a deal and promises delivery in 5 business days. Legal takes 15. The client complains. Sales blames legal. Legal says they lacked context. Management does not know who is right because there is no record of when the request came in, when it was handled, and how long each step took.
This scene repeats in companies of all sizes. The problem is not lack of competence. It is lack of a formal agreement between departments about deadlines, responsibilities, and consequences.
That agreement has a name: internal SLA.
What is an internal SLA
SLA stands for Service Level Agreement. When applied between departments within the same company, it defines the expected deadline and quality for an internal delivery.
An external SLA is the one you make with the client: support response time, product delivery deadline, system availability. An internal SLA follows the same logic, but between areas of the organization.
Practical examples:
- Legal: review and return a contract within 3 business days after receipt
- IT: provision access for a new employee within 1 business day after HR request
- Finance: process reimbursement within 5 business days after manager approval
- HR: complete hiring process within 7 business days after position approval
- Procurement: issue purchase order within 2 business days after budget approval
The difference between an SLA and a "deadline agreed by email" is that the SLA is documented, measurable, and has consequences when not met.
Why internal SLAs matter
The cascade effect of internal delays
When one department is late, the impact rarely stays contained. The delay propagates.
HR takes long to complete a hire. The new employee starts without system access. IT receives the request at the last minute. The area manager loses the first productive days of the new hire. The project that depended on that hire is delayed.
Every step without a defined deadline is a step where delays can settle in unnoticed — until the impact reaches the end customer or financial results.
Accountability without conflict
Internal SLAs do not exist to punish. They exist to create clarity.
When everyone knows the expected deadline, the conversation changes. Instead of "legal always takes too long," the discussion becomes "legal met the SLA in 87% of cases last quarter — what is causing the 13% delay?"
Data replaces perceptions. This reduces conflicts between departments and enables fact-based decisions.
Visibility for management
Without SLAs, management only discovers bottlenecks when they become crises. With measured SLAs, it is possible to identify patterns before they become problems: a department that consistently exceeds the deadline, a type of request that always delays, a period of the month with peaks the team cannot absorb.
Common internal SLAs by department
IT
| Request | Suggested SLA |
|---|---|
| Provision access for new employee | 1 business day |
| Resolve high-priority ticket | 4 hours |
| Resolve medium-priority ticket | 1 business day |
| Install software or equipment | 2 business days |
| Evaluate new tool or integration | 5 business days |
Legal
| Request | Suggested SLA |
|---|---|
| Review standard contract | 2 business days |
| Review custom contract | 5 business days |
| Issue legal opinion | 3 business days |
| Register trademark or patent | 10 business days |
HR
| Request | Suggested SLA |
|---|---|
| Complete hiring (full documentation) | 5 business days |
| Process termination | 3 business days |
| Respond to vacation request | 2 business days |
| Update benefits registration | 1 business day |
Finance
| Request | Suggested SLA |
|---|---|
| Process reimbursement | 5 business days |
| Issue invoice | 1 business day |
| Approve project budget | 3 business days |
| Deliver monthly report | 5 business days after closing |
How to define internal SLAs
1. Identify deliveries between departments
Start by mapping what each department delivers to others. Do not try to map everything at once. Focus on deliveries that cause the most friction or directly impact the end customer.
2. Measure current time
Before defining an SLA, understand how long the delivery takes today. If legal takes an average of 8 days to review a contract, there is no point setting an SLA of 2 days. Start with a realistic deadline and reduce gradually.
3. Define what counts as "entry" and "exit"
One of the most common mistakes is ambiguity about when the deadline starts. Does legal's SLA start when sales sends the email? When the contract arrives with all necessary information? When the legal manager assigns it to a lawyer?
Define precisely: the deadline starts when the request arrives complete, with all necessary information and documents. Incomplete requests do not activate the SLA.
4. Establish consequences and escalation
An SLA without consequences is a suggestion. Define what happens when the deadline is exceeded:
- Automatic alert to the responsible person when 80% of the deadline has passed
- Manager notification when the SLA is breached
- Escalation to director if the delay exceeds 2x the SLA
- Monthly review of compliance rates by department
5. Review periodically
SLAs are not permanent. Request volume changes, teams grow or shrink, new types of requests emerge. Review SLAs quarterly.
The problem with informal SLAs
Most companies already have SLAs — they just do not know it. They are verbal agreements, arranged by email, defined in meetings nobody documented.
The problem with informal SLAs:
- Not measurable: without records of when the request entered and exited, there is no way to calculate actual time
- Not consistent: each person in the department applies a different deadline
- No escalation: when the deadline is breached, nobody is notified automatically
- No data: without history, it is impossible to identify patterns or justify new hires
Turning informal SLAs into formal ones does not require bureaucracy. It requires a tool that automatically records timestamps and calculates deadlines.
How to implement SLAs with a process platform
Stage deadlines
In a process orchestration platform, each request moves through stages. Each stage can have a configured deadline.
Example — contract review process:
- 1Request received (deadline: 0 — entry record only)
- 2Under legal review (deadline: 3 business days)
- 3Awaiting requester adjustments (deadline paused — the clock stops)
- 4Final review (deadline: 1 business day)
- 5Completed
The total SLA time is the sum of stage deadlines under the department's responsibility. When the request is waiting on the requester, the department's clock stops.
Automatic time measurement
The platform automatically records when each request entered and exited each stage. With this data, you calculate:
- Average time per stage: how long each step takes on average
- SLA compliance rate: percentage of requests handled within the deadline
- Trend: is the time increasing or decreasing over the months
- Outliers: requests that took much longer than normal and why
Alerts and escalation
Configure automatic alerts:
- Notification to the responsible person when the deadline reaches 80%
- Alert to the manager when the SLA is breached
- Escalation to the next level if the delay persists
Without alerts, SLAs become numbers in a spreadsheet nobody checks.
SLA dashboard
A centralized panel shows the status of all SLAs in real time: how many requests are on track, how many are at risk, how many have already breached. The manager sees the operational health of the department without asking each person.
How CaseFy solves this
In CaseFy, each process template allows configuring deadlines per stage. When a case moves to a new stage, the clock starts automatically.
The timeline records each transition with a timestamp. Reports show average time per stage, compliance rate, and overdue cases. Automations send alerts when deadlines approach or are breached.
The result: internal SLAs that leave email and become actionable data.
You define the process, configure the deadlines, and the platform handles the tracking. No parallel spreadsheets, no manual reminders.