Request Automation: From Intake to Completion

A request is not an event but a process of several stages, and it can get stuck at any of them. Below we walk through the request lifecycle step by step: how it enters the system, by which rules it is assigned to an owner, how deadlines are counted, and what the system does when a stage runs overdue. The focus is on the mechanics - rules, timers, escalations and automatic notifications.

Request intake: a single entry point and data normalisation

The first stage of the cycle is intake. No matter where the request came from, in the system it must become a uniform object with a predictable set of fields: who submitted it, what is needed, which product or service it relates to, which region, which priority. As long as requests exist in different formats, no routing rules will work, because they have nothing to key off.

Normalisation is not only mapping fields. It also means aligning values with reference lists: a phone number in international format, a city name from a single list, a request type from a fixed set. Then a condition like «if type = service and region = West» works unambiguously instead of depending on how a manager typed the city into a free text field.

Deduplication belongs here too: if a client wrote twice within fifteen minutes, that is one request with two messages, not two tasks for two different people. A practical rule is that a match by phone or email within a 24 hour window merges the enquiries into a single thread. The same applies to a repeat request on an issue already in progress: it is attached to the existing card instead of starting a parallel process.

Request routing: assignment rules instead of manual picking

Once a request is normalised, rule based routing kicks in. There are usually four basic criteria: product or service type, region or client language, the current workload of an owner, and the on duty schedule. Rules run top to bottom, and the first match determines the request owner.

Workload should be counted not by total requests but by active ones - those in progress right now. If a manager has eight open requests against a limit of ten, they are still in the queue; past the limit new requests go to the next person. This is more even than plain round robin because it reflects actual load. The duty schedule adds a time dimension: the rule checks who is actually on shift when the request arrives and never assigns it to someone on holiday or outside working hours.

A default rule is mandatory: if no condition matched, the request goes to the on duty manager or into a shared queue with its own alert. An unowned request is the most common cause of silent loss, so the state «assigned to nobody» must be technically impossible for longer than a few minutes.

Statuses and deadlines: SLA timers at every stage

Statuses and deadlines form the backbone of the whole process. A minimal working set of statuses: new, assigned, in progress, waiting for client, done, closed. Each status has its own timer: for example 15 minutes for first contact, 4 hours for assessment, 2 business days for delivery. The timer starts on entering the status and stops on moving on.

An important detail is that the timer must respect the working calendar. A request that arrived at 19:40 on Friday should not count as overdue on Saturday morning if you have no night shift. Likewise the «waiting for client» status should pause the SLA, otherwise metrics will show a failure where the team actually did fine.

Transitions between statuses should be constrained: from «new» you can only move to «assigned», and the system does not allow closing a request that skipped the «done» stage. This removes cases where a request is closed in one click just so it stops spoiling the statistics. If a transition requires a reason - a client refusal or a duplicate, for instance - the reason is picked from a list and stored with the request.

Execution control: escalating overdue requests

Execution control rests not on daily meetings but on the system reacting automatically. Escalation is usually three tiered: at 20 percent of time remaining - a reminder to the owner, at the moment of breach - a notification to the team lead, at double the deadline - a priority bump and a message to the department head.

Escalation must change something rather than just send emails. Useful actions include automatically reassigning the request to the on duty person, moving it to the top of the queue, or blocking an owner with an overdue item from taking new requests. Otherwise notifications quickly turn into background noise everyone ignores. Practice shows that if no automatic action is wired to an escalation, within two or three weeks the team stops reading it.

It is worth keeping the list of overdue requests as a working queue rather than a report. Every item on it must be closed by an action: extend the deadline with a reason, reassign, return to the client, or close. If breach reasons are recorded in a structured way, after a month it becomes clear which stage needs rebuilding.

Client notifications at every status change

Client notifications close the loop and remove most repeat enquiries. The rule is simple: every status change the client can feel is accompanied by a short message. Accepted, owner assigned, deadline set, completed, closed - five touchpoints are enough in most cases. The text should fit into two sentences and answer the main question a client has: what is happening and when there will be a result.

Messages are best sent through the channel the request came from, with the request number included - the client then replies in the same thread and the reply is attached to the request automatically. If a deadline shifts, the notification must go out before it, not after: a warned delay is taken calmly, a discovered one feels like a breakdown.

Put together, this cycle produces a predictable process: a request is not lost at intake, always has an owner, lives by timers and signals problems on its own. At Devlly we build such systems around the specific processes of each company - with your routing rules, statuses and deadlines rather than a universal template.