Approvals Without a Workflow Engine or an Approval Step

Tuesday, 11:20, at Northgate Retail. Ticket 3310 reads "New laptop for Ayesha, assistant manager at the Harbor Street store, starts Monday." Dana knows the rule: hardware for a new starter needs the regional manager's approval before anything is ordered. The ticketing tool has no approval button. So she does what everyone on the desk does. She forwards the ticket from her own mailbox to Greg, the regional manager, with "OK to order?" at the top. Greg replies "yes, go ahead" at 15:40, to Dana's inbox. Dana is off sick on Thursday and Friday. On Monday morning Ayesha arrives at the Harbor Street store and has no laptop. The store manager phones the desk. The technician who picks up finds ticket 3310 in a status called Awaiting Approval. It has no name, no date, and no sign that anyone had ever said yes. The approval existed. It was in a drawer, and the drawer was off sick.

An approval is a recorded yes, from a person entitled to give it, obtained before the work is done. All three parts matter. Recorded, because an approval nobody can find later did not happen as far as anyone later can tell. From a person entitled, because a yes from the wrong person is a conversation, not an authorisation. Before the work, because an approval after the fact is an apology with a signature. Many large service management suites have a workflow engine for this. It is a feature that routes a request to the right approver, holds it until they answer, reminds them, and records the answer as a step in the ticket. Most small-team help desk tools have nothing of the kind, and this article is about doing the job without one. It is part of our Ticket Workflow Automation series.

It covers what an approval is and why the engine is optional. Next comes the approver list by request type, which is the piece most desks are missing. Then we cover capturing the approval in the approver's own reply on the ticket, and what counts as an approval and what does not. We move on to linked tickets for the approval and the work, then the waiting status and the chase. We finish with self-approval and emergencies, a short war story, and the approval convention to copy. The lifecycle of a request from ask to fulfilment is in Requests, Approvals and Fulfilment. This article is the mechanics of the approval step inside it.

Why the Engine Is Optional

A workflow engine does four things for an approval. It knows who should approve a given request, it asks them, and it waits and reminds. And it writes the answer into the ticket in a way a report can count. None of those four needs an engine. The first is a list. The second is a message sent from the ticket. The third is a waiting status with a follow-up date. The fourth is the approver's reply landing in the ticket's history under their own name. A desk of five that writes those four things down as a convention has an approval process that a desk of five hundred with an engine would recognise. The engine makes the convention harder to skip. It does not make it exist.

The engine's real advantage is at volume, where a desk handles dozens of approvals a day and the reminders alone would be a job. Below that, the convention is faster to set up and easier to change when the approver changes. It is far easier to explain to the approver, who is a store manager or a finance lead with no interest in learning a portal. Greg will reply to an e-mail. He will not log into anything. A convention built on the reply is built on the one thing every approver already does.

The convention also survives a change of tool, which an engine configuration never does. Approvals captured as replies on tickets are in the ticket history, exportable, readable by anyone, and still meaningful in whatever system comes next. An approval recorded as "step 3 of workflow 14 completed" means something only while workflow 14 exists. For a small desk that will change tools once or twice in a decade, the dull version is the durable one.

The Approver List by Request Type

The piece most desks are missing is not the engine but the list. For each kind of request that needs approval, it says who is entitled to say yes. It says who deputises when they are away, and what the yes has to say. Without the list, every approval starts with a technician guessing who to ask. The guess is usually "the requester's manager", which is right for a laptop. It is wrong for admin rights, a shared mailbox, a software purchase, or access to the finance system. Each of those has an owner who is not the line manager. The list is written once, by the desk lead with the people on it, and it lives on the desk's scope page where the technicians can see it.

The table below is the shape of the list, with example rows from Northgate after Dana's Monday. Keep it short. If more than eight request types need approval, several of them probably do not, and the article on What Needs Review and What Does Not is the argument for pruning. Everything not on the list is approved by the desk, meaning the technician does it. That is written on the list too, so that nobody waits a week for a yes that was never required.

Two columns do the heavy lifting. "The yes must state" is what turns a reply of "fine" into an approval. An approval for "a laptop" is not an approval for the laptop with the larger screen that the requester mentions on Thursday. "If no answer after two chases" is the pre-agreed escape, so that a silent approver produces a decision from someone else rather than a ticket that waits forever. Agree both with the approvers when the list is written. They will agree to almost anything that means fewer e-mails from the desk.

Capturing the Approval in the Approver's Reply

The approval is captured by asking from the ticket and having the answer land in the ticket. The technician sends the request to the approver as a reply on the ticket, adding the approver's address, rather than forwarding it from their own mailbox. The approver replies, as approvers do, with "yes, go ahead" or "no" or "yes but only the standard model". Because the reply carries the ticket's reference it threads onto the ticket, under the approver's name, with a timestamp, where every technician on the desk can see it. Dana's mistake on Tuesday was not asking Greg; it was asking him from a place the desk could not see.

The ask has to be written so that the reply can be an approval. State what is being requested, for whom, at what cost or risk, and what "yes" will cause to happen. "Greg, Ayesha at Harbor Street starts Monday; the request is for a standard laptop against cost centre 4410, to be ordered today for delivery Friday. Please reply to this message with your approval or any change." An approver who receives that can reply "approved" and the reply means something. An approver who receives a forwarded ticket with "OK?" at the top has to work out what they are approving. They will reply "what is this?", which is a chase in the wrong direction.

If you run QuerySolv, replies to a ticket thread onto it and every event sits in the ticket's history. That means the approver's yes lives in the same place as the work it authorised, without anyone keeping a separate file. In any tool, that is the standard to aim for: open the ticket in a year and see who asked, who was asked, what they said, and when. The ticket is the record. The inbox is where records go to be lost.

What Counts as an Approval

An approval is a reply, in the ticket, from the approver's own address, that says yes to the thing the ask described. It is not a requester writing "Greg said it's fine", however honest the requester. In that case, the desk is being asked to act on a report of a conversation it did not see. It is not a screenshot of a chat message, because screenshots are not in the ticket and prove only that a message once existed on someone's screen. It is not a verbal yes in the corridor, which the approver will not remember and the technician will not be believed about. And it is not a yes to a different question: approval for one laptop does not cover two, and approval for standard admin rights does not cover the domain.

When the yes arrives in the wrong form, the technician converts it rather than refusing it. "Thanks, Priya; so the desk has it on record, I've asked Greg to confirm on the ticket and will order as soon as he does." A chat message from Greg is answered with "could you reply on the ticket as well, so it's with the request?" A corridor yes is followed by the technician sending the ask from the ticket with "as discussed, please confirm here". None of this is distrust. It is the desk making sure that the approval will still exist when the approver has forgotten the conversation, which is the only time anyone will ask for it.

Conditions in the reply are part of the approval and go into the work. "Yes, but the standard model only" means the standard model is ordered, and if the requester wants the other one, that is a new ask to the same approver. Where the request is an exception to a rule rather than a routine request, the approver is the rule's owner. In that case, the yes should carry a time limit, a scope and a review date. The whole conversation is the one described in Saying No Upward. A routine approval and an exception look similar on the ticket. They differ in what the yes has to contain.

Linked Tickets for the Approval and the Work

Most approvals fit on the request ticket itself: the ask, the yes, and the fulfilment all happen in one ticket, and the history reads in order. Two situations want a second, linked ticket. The first is when the approval and the work belong to different teams. The request comes to IT, but the approval belongs to finance. Finance wants its approvals in its own queue where its own people can see what is waiting on them. The desk raises a linked ticket in the finance department with the approver as requester. The yes arrives in that ticket. The IT ticket carries a link to it and a note saying "approved in 3318 by Greg". The work waits on the link.

The second situation is a request that needs several approvals, or an approval that unlocks several pieces of work. A new starter needs a laptop, an account, a phone and access to two systems, each with a different approver. One parent ticket holds the request and the start date. One child ticket per piece of work holds its own approval and its own fulfilment. The parent is resolved when the children are. Linking is a basic feature of nearly every ticketing tool. It is the closest a small desk gets to a workflow with stages. That means not a sequence enforced by an engine, but a set of related tickets each with one approval and one owner, visible together.

Whichever shape you use, the rule is that each approval lives in exactly one ticket and every ticket that depends on it carries the link. A technician picking up the laptop ticket should be able to click once and see Greg's yes, not search a mailbox for it. The linking itself takes seconds. Deciding which ticket is the approval's home, and writing that into the convention, stops three technicians each asking Greg separately about the same new starter, which Greg will not enjoy.

The Waiting Status and the Chase

While the approval is outstanding, the ticket sits in a waiting status, usually the same one used for waiting on the requester. It has a note saying who was asked, when, and when the chase is due. The status takes the ticket out of the active list, which is correct, because the desk cannot act on it. The note and the follow-up date are what stop it disappearing. A waiting ticket with no date is a ticket that waits forever and an approver who was never chased has never been asked twice. The mechanics of a waiting status that does not become a hiding place are in the Ticket Workflow and Status series. For approvals, the point is that "Awaiting Approval" without a name and a date is a status that lies.

Chase on the interval in the list, from the ticket, to the approver, with the original ask quoted and one line added: "Greg, this needs your yes by Thursday for Ayesha to have a laptop on Monday; could you reply here?" Chase once more at the same interval if nothing comes back. After the second chase, the pre-agreed escape in the list takes over. The desk lead asks the approver's manager for a decision. Or, for the request types where silence means no, the requester is told that the approval was not given and why. The technician never approves in the approver's absence, and never assumes silence is consent, however obvious the yes would have been. Writing follow-ups that approvers actually answer, as opposed to ones they file, is the subject of Follow-Up Messages That Get Replies.

Tell the requester what is happening at each step. "Your request is waiting on Greg's approval; I asked on Tuesday and will chase on Thursday if I haven't heard." The requester knows where the delay is and whom it belongs to. That is nearly always enough to stop them chasing the desk. It is quite often enough to make them chase Greg, which is faster. A requester who knows the approval is pending is a patient requester. A requester who sees "Awaiting Approval" and nothing else is drafting a complaint.

Self-Approval and Emergencies

An approver cannot approve their own request. When Greg asks for a laptop for himself, the approver is Greg's manager. When the IT manager asks for admin rights on a device, the approver is whoever the list names as the IT manager's deputy or manager. Most desks discover this rule the first time an auditor asks about it, which is a poor time to discover anything. Write it into the convention: the approver for a request raised by an approver is the next name up. The list already has a deputy column; the self-approval case uses the manager, not the deputy, because the deputy reports to the approver.

Emergencies happen, and the convention has to say what an emergency does to the approval rather than pretend there are none. At two in the morning with the finance system down and the only fix needing a change nobody has approved, the technician does the work. In that case, they record what they did and why in the ticket. They obtain the approval afterwards from the same approver the list names, with the word "retrospective" in the note. The approval is still recorded, still from the entitled person, and is now honestly marked as having come after. The one thing not to do is to skip the record because the moment was urgent. The record is what distinguishes an emergency from a habit. And a desk that has twelve "emergencies" a month has a habit with a dramatic name. Emergency changes to shared systems have their own routine, in the Lightweight Change Management series, and the approval step there follows the same shape.

A Short War Story: The Fourteen Laptops at Pennard Marine

At Pennard Marine, a boatyard and chandlery with ninety staff, hardware approvals came from department heads by whatever route was quickest. In practice that meant a chat message to a technician called Josh. He kept the messages on his phone and bought what they said. The yard's operations head approved laptops that way for eighteen months, then left, and his account and its chat history went with him. Six months later the finance manager, reconciling the asset list against the purchase ledger, found fourteen laptops bought for a department of nine people. The manager asked the desk to show the approval for each one. Josh could produce five, from tickets where the department head had happened to reply by e-mail. The other nine existed only in a chat history nobody could open. The purchasing freeze that followed lasted three weeks. Every pending hardware request stopped dead. The review spent most of its time establishing that nobody had done anything dishonest, which is an expensive thing to have to establish. Pennard now asks for every approval from the ticket and accepts only replies that land in it. Josh wrote the lesson on the approver list himself: an approval the ticket cannot show did not happen, as far as anyone who asks later can tell.

The Approval Convention

The convention below is the whole process on one page, written as the rules the desk follows for every request type on the approver list. Fill in the list first, then the chase interval, then the two names at the bottom. Read it aloud to the approvers once. That is because the convention works only if they know that a reply on the ticket is what the desk is waiting for. The internal-note prefix in the third block is what makes approvals countable in a tool with no approval field. A filter for notes beginning "APPROVAL:" finds every one, and the monthly count of approvals asked, given, declined and silent comes from that filter.

THE APPROVAL CONVENTION — ONE PAGE
Desk: ______________________   Owner of this page: ______________   Reviewed: __________

1. WHAT NEEDS APPROVAL
   Only the request types on the approver list need an approval.
   Everything else is approved by the desk and done without waiting.
   Approver list location: ______________________________

2. HOW TO ASK
   Ask from the ticket, as a reply, adding the approver's address.
   The ask states: what ____ for whom ____ cost or risk ____ what "yes" causes ____
   Never forward the ticket from a personal mailbox.
   Set status to waiting; add internal note:
     "APPROVAL: asked [approver] on [date]; chase due [date]"

3. WHAT COUNTS AS A YES
   A reply, on the ticket, from the approver's own address, agreeing to the ask.
   Conditions in the reply are part of the approval and go into the work.
   Does NOT count: requester reporting a yes, a chat screenshot, a verbal yes,
   a yes to a different question. Convert these by asking again from the ticket.
   On receipt, add internal note:
     "APPROVAL: given by [approver] on [date]; conditions: ______________"

4. CHASING
   First chase after ____ business days, from the ticket, quoting the ask.
   Second chase after a further ____ business days.
   After two chases with no reply: ______________ (desk lead) asks ______________
   (approver's manager) for a decision, or the request is declined if the list says so.
   Requester is told at each step who the request is waiting on.
   Never approve in the approver's absence. Silence is never consent.

5. LINKED TICKETS
   Approval owned by another department: raise a linked ticket there with the
   approver as requester; note "approved in [ticket] by [approver]" on the work ticket.
   Several approvals or several pieces of work: one parent, one child per item,
   each child with its own approval. Parent resolved when children are.

6. SELF-APPROVAL AND EMERGENCIES
   An approver's own request is approved by their manager, not their deputy.
   Emergency work done before approval is recorded in the ticket at the time and
   approved retrospectively by the listed approver; note says "APPROVAL: retrospective".

7. MONTHLY COUNT (from the APPROVAL: note filter)
   Asked ____   Given ____   Declined ____   Still waiting past second chase ____
   Longest wait: ____ days, request type ______________, approver ______________
   Signed: ______________ (desk lead)   ______________ (one approver, on behalf of the list)

Northgate's convention took Dana and the desk lead an afternoon to write and Greg about four minutes to agree to. He spent most of that asking whether it meant fewer e-mails from the desk, which it did. Ayesha got her laptop on the Wednesday. Ticket 3310 now shows Greg's "yes, go ahead" at 15:40 on the Tuesday. That is because Dana forwarded it into the ticket from her inbox when she got back. She added a note that says "approval received here while I was off; should have been asked from the ticket". It is the most useful note on the desk, and she wrote it about herself.

Frequently Asked Questions