tiqline is a process SLA monitoring tool: it turns events from Shopify and your own systems into one case per piece of work, gives every step a time limit and alerts you in Slack or by email when a step runs over.
Business process SLA monitoring: a time limit for every step, across every system
A service level agreement is a promise about time: an order ships within a day, a prescription is checked within two hours, a new customer is set up within three days. Keeping that promise depends on several steps in several tools. tiqline follows each case through those steps, compares every step with its own limit and alerts the moment one runs over.
The problem: the SLA lives in one place, the steps in many
Few processes run in one tool. An order starts in the shop, is packed in a warehouse system and handed over in a carrier portal. A B2B order is approved in the ERP, checked by finance and confirmed by email. A prescription is issued, checked by a pharmacist, packed and delivered. Each tool knows its own step. None of them knows whether the whole case is on time, and none of them alerts when the hand-over between two tools is where the time is lost. The overall SLA is then measured at the end, if at all, once it is already broken.
How teams measure process SLAs today
Ticket systems are the best-known SLA tools. Jira Service Management, for example, defines SLAs with goals, calendars for working hours and start, pause and stop conditions, all for work items inside the service project. That fits support requests. It does not follow an order or a prescription through a shop, a warehouse system and a carrier. Outside ticket systems, teams build reports from exports in Excel or Google Sheets, write scheduled database queries, or chain automations in Zapier or n8n with delay and wait steps. Process mining tools reconstruct processes from event logs and show where time goes, which is analysis after the fact rather than an alert while a case can still be saved.
What a process SLA monitor has to do
It has to recognise one case across events from different systems, know which step the case is on, know the limit for that step and react when the limit passes, for every case at once and without someone running a report. It also has to let you change a limit or a step without rebuilding everything.
How tiqline monitors a business process
1. Send events from every system
Systems send events to the track API in the Segment and RudderStack format, one at a time or in a batch. Shopify can be connected directly. Each event has a type, such as Prescription Issued, a time and properties. You tell tiqline which property identifies the case, such as the order ID or the prescription ID.
2. Model the process
A process has an anchor, the object a case is built around, and steps in the order they should happen. Other object types can belong to a case as a tree, so every prescription of an order or every shipment of an order is followed as its own sub-case with its own steps. A branch sends a case down one of several paths based on a property, and paths can meet again in a shared step.
3. Set the limits
Each step after the first can have a limit from seconds to 3,650 days, for example 2h or 3d. Steps can be optional, so a case that does not need them waits for the next required step. A conversion step records that a case reached a point without ever raising an alert. End rules close a case early for a good reason, such as a cancellation.
4. Preview, publish and change
You edit a draft and preview it on your real cases before you publish it. Cases are built from the events that are already stored, so you see today's state straight away. A changed limit applies at once, also to cases already waiting on the step.
5. Alerts and the overview
When a case passes a limit, or skips a required step, tiqline opens an incident for that step and alerts once in Slack, by email to up to 20 people or through a signed webhook. Per process you see the share of finished cases that kept every limit, how many are stuck now and how long a case usually takes, on a process map drawn from real cases. Every plan includes the audit log, including Free. Publishing a process, changing a time limit and connecting Slack or email are written to it, with the person or app that did it.
Example: prescriptions at an online pharmacy
The pharmacy, the limits and the times are made up to show the flow. The process: Prescription Issued opens the case, Prescription Checked has 2 hours, Order Packed has 4 hours, Order Delivered has 48 hours.
08:05: a prescription is issued
The prescription system sends Prescription Issued with the prescription ID. tiqline opens a case and sets the check deadline to 10:05.
09:20: the pharmacist checks it
Prescription Checked arrives within the limit. The case moves on, and the packing deadline is 13:20.
13:20: packing is overdue
Stuck
The warehouse system sent nothing for this case. The case turns stuck on Order Packed, and the team gets one email for this step that lists the waiting cases.
13:45: packed, and the incident closes
A missing item was restocked, Order Packed arrives, the case moves on to delivery with 48 hours, and the incident is resolved because no case is stuck on packing any more.
What tiqline does not do
tiqline has no business-hour calendars and no pause conditions: a limit runs on the clock, nights, weekends and holidays included. It measures time between events, so a step that sends no event is invisible until you send one. It has no ready-made connectors besides Shopify and the track API, and no templates: you or an AI agent describe the process. It does not explain why a step was slow and does not do root-cause analysis; it tells you which cases are late, where and since when. Each organisation has one Slack channel, one email list and one webhook for alerts.
Ticket SLAs, process mining and process SLA monitoring
Use your ticket system's SLAs for support requests that live inside it. Use process mining to analyse months of history and redesign a process. Use tiqline when a case crosses several systems and you want to know during the case, not afterwards, that a step is running over.
tiqline monitors process SLAs and is not one of the classic product-analytics tools.
Questions about business process SLA monitoring
What counts as a business process here?
Any sequence of steps that systems report as events with a shared ID: an order, a prescription, an onboarding, a return or an approval. One case follows one anchor object, such as one order.
How does tiqline calculate a deadline?
The deadline of a step is the time the case reached the previous step plus the step's limit. The time is the time the event happened, not the time it arrived.
Can a step have no limit?
Yes. A step without a limit never alerts, and a conversion step only records that a case reached it.
Does tiqline support working hours?
No. Limits run on the clock, including nights and weekends. Choose the limit with that in mind, for example 3d instead of two working days.
Can sub-steps be followed separately?
Yes. Object types such as a shipment or a prescription can belong to a case, and each one is followed as a sub-case with its own steps and limits.
Where is the data stored?
In the EU, in Frankfurt. From Shopify, tiqline keeps order and fulfilment facts and never copies customer names, email or postal addresses, phone numbers or notes.
Start for free
The Free plan includes 5,000 events a month.