The Complaint That Starts No Clock
Indian e-commerce rules give a grievance officer forty-eight hours to acknowledge a complaint and one month to redress it, both counted from the date it was received. Three things in an ordinary help desk decide whether those periods are measured at all — and the one that matters most is not a clock, it is whether the ticket was filed anywhere.
Rule 4(5) of the Consumer Protection (E-Commerce) Rules, 2020 is two sentences long and contains two deadlines. The grievance officer acknowledges receipt of a consumer complaint within forty-eight hours, and redresses it within one month from the date of receipt. Rule 4(4), just above it, says the officer's name, contact details and designation are displayed on the platform.
That is a short, clear obligation, and it is the kind of thing everyone assumes their help desk handles, because a help desk is obviously the piece of software that has deadlines in it. Whether it does depends on three settings, and they fail in ascending order of how quietly they fail.
Failure one: the clock counts a different kind of time
Most help desks let you choose how a deadline counts. Real elapsed time — forty-eight hours means forty-eight hours, weekend or not. Or working time — only the hours your organization is open, skipping weekends and public holidays. Both are correct, for different promises.
We have argued the working-hours case ourselves, at some length, in a post about a tenancy agreement promising a response "within one working day". A contract written in working days and a system counting wall-clock hours agree from Monday to Thursday and part company on Friday afternoon, and the working clock is unambiguously the right answer there.
A statutory period is the opposite case, and the same setting that fixed the contract breaks it.
Forty-eight hours, expressed as a category setting
Seven calendar days where the rule allowed two — and nothing anywhere reports a problem, because the clock is doing precisely what it was configured to do. The working day and the working week here are the example's assumptions; yours are whatever your calendar says, which changes the number and not the point.
So the first question about any statutory deadline is not "does the system have SLAs" but "which of its two kinds of time is this category counting". A demonstration will not show you: both clocks look identical in a screenshot taken on a Tuesday.
Failure two: one of the two deadlines can be paused, and one cannot
Almost every help desk pauses a resolution deadline while you are waiting on the customer to answer a question, and it is a defensible piece of design: an agent should not be judged on time the other party spent thinking. Ours does it, and it does it carefully — at the moment of the pause the ticket has some budget left, and on resume it gets exactly that much again.
The acknowledgement deadline is treated differently, and the reason is worth stating because it happens to be exactly what Rule 4(5) needs. Our breach check leaves the first-response clock running through a pause deliberately, on the ground that a ticket cannot be waiting on a requester nobody has answered yet. So the forty-eight-hour leg has no way to be extended by a conversation.
The one-month leg does. Ask a consumer for their order number, wait nine days for the reply, and the system's deadline is nine days later than the rule's. Both are visible on the ticket. Only one of them is the law, and nothing on the screen distinguishes them.
Acknowledge — 48 hours
- Runs from the moment the complaint arrives
- Cannot be extended by waiting on the consumer
- Maps onto a first-response target with no adjustment
- Correct on the default clock, which counts real time
- The leg an ordinary help desk gets right by accident
Redress — one month
- Also runs from the moment the complaint arrives
- Pauses in our system whenever you are waiting on a reply
- Drifts later every time the conversation goes quiet
- Still shows as comfortably within target while it drifts
- The leg to configure deliberately, or to track outside
Failure three, and this is the one
Both of the above assume the complaint landed in a category. Categories are where the deadlines live — the number of minutes, and which kind of time to count, are settings on the category rather than on the ticket.
We have a public complaint form. Anyone can raise a ticket on a workspace's public page without an account, and it is a genuinely good piece of the product: the person is identified by name and email, matched to an existing customer record where the email is already known, protected by a verification challenge and rate limiting, and emailed a signed link to track and reply to their own ticket. It is exactly the channel a consumer complaint arrives through.
And a ticket raised on it has no category
Which means it has no first-response deadline and no resolution deadline. Not a late clock — no clock. The ticket is created, the agents are notified through the department queue, the requester gets their tracking link, and every deadline field on the record is empty. The breach check runs every fifteen minutes and finds nothing to report, correctly, because a ticket with no target cannot miss one. This is on our list to fix and it is stated in the ledger below.
A missed deadline generates an alert. A deadline that was never set generates a ticket that looks fine for a month.
What to actually do about it this week
There is a workaround, it is real, and it works because of a design decision made for an unrelated reason. Deadlines are anchored on the moment the ticket was created, not the moment somebody triaged it — and they are recomputed whenever the category changes. So filing an untriaged public complaint into a category on Monday morning sets a deadline measured from when it actually arrived on Saturday.
-
Make one category for consumer complaints
Separate from your ordinary support categories, because it is the one with a legal period on it rather than a service target.
-
Set the acknowledgement target on real elapsed time
Two thousand eight hundred and eighty minutes, on the clock that counts calendar hours. That is the setting that matches the rule, and it is the default.
-
Set the resolution target short of a month
Deliberately short, because the resolution clock pauses while you wait on the consumer and the statutory month does not. How much shorter is a judgement about your own conversation lengths.
-
Triage the public queue every working day
Until a default category exists, this is the step that starts the clock. The anchor protects you from a late triage; it does not protect you from no triage.
-
Publish the officer beside the form
Name, designation and contact details, as Rule 4(4) asks. Today that is a block on your own page rather than a field in ours.
Four small builds, and the first one is a setting
None of what follows is a new module. They are the difference between a help desk that can carry a statutory deadline and one that can carry a service target, and we would quote them as a single short piece of work.
A default category for public intake
So a complaint that arrives through the public form is on a clock the moment it lands, with no dependency on somebody opening the queue.
A published grievance officer
Name, designation and contact details rendered on the intake page, and the tickets from that page owned by them — the shape Rule 4(4) describes.
A resolution clock that ignores the pause
Per category, so a statutory month keeps counting through a conversation while your ordinary support categories keep the behaviour that is right for them.
Public intake chosen per category
So the consumer route and the general enquiry route can be two different categories with two different sets of deadlines behind one form.
The first is a setting and a default. The other three are ordinary work on a module that already has the clocks in it.
Tell us what your operation needsFour questions for whoever is selling you a help desk
Does a ticket raised on your public form get a deadline?
What you will probably hear
Almost always yes, said quickly, and often without checking.
How to read it
Ask them to raise one in front of you and show you the due date field. This is a thirty-second test and it is the single most useful question on the list, because the answer people give and the answer the software gives are frequently different.
Does your response deadline count working hours or real hours?
What you will probably hear
Working hours, usually offered as a feature.
How to read it
It is a feature, and for contractual promises it is the right one. Ask whether the choice is per category, because you need both kinds in one system: statutory periods count calendar time and service promises count working time.
What pauses each of your two clocks?
What you will probably hear
A description of waiting on the customer.
How to read it
Ask specifically whether it pauses the acknowledgement clock too. If it does, a first response can be indefinitely deferred by a system that reports it as on target — and for a period defined by a rule, no pause is correct on either leg.
If I categorise a ticket two days late, when is it due?
What you will probably hear
Hesitation, then usually "from now".
How to read it
From now is the common behaviour and it quietly grants an extension for being slow to triage. From receipt is the honest one. Ours measures from receipt, which is the only reason the workaround in this article holds.
The short version
A legal deadline and a service target look identical inside a help desk and behave differently in three ways: what kind of time they count, whether a conversation can extend them, and whether they exist at all on a ticket nobody has filed. The forty-eight-hour leg of Rule 4(5) maps cleanly onto an ordinary first-response target on the default clock, and that is a real and useful thing to know. The one-month leg needs a target set deliberately short, because ours pauses and the rule does not. And a complaint arriving on the public form carries no target at all until somebody triages it — which is our gap, it is on the list below, and until it closes the answer is a category assigned every working day.
What AWRA OpsHub does today
- A public complaint form with no login, switched on per workspace, with the person identified by name and email, matched to a customer record where the email is already known, and emailed a signed link to track and reply to their own ticket.
- Verification, timing and rate-limiting protection on that form, so a public intake stays usable when somebody points a script at it.
- Acknowledgement and resolution targets per category, anchored on the moment the ticket was received rather than the moment somebody triaged it — so filing a complaint into a category later still measures from arrival.
- Two kinds of time to choose between, per category — real elapsed hours, or only the hours your organization works, skipping weekends and public holidays.
- An acknowledgement clock that a pause leaves alone. Waiting on the requester stops the resolution clock and deliberately holds the first-response clock where it is, because a ticket is not waiting on somebody who has never been answered.
- A breach check every fifteen minutes, notifying once on each of the two targets separately, and a default assignee who is skipped when they have left or been suspended.
More we can add to your workspace
- A deadline on a ticket that arrives without a category, so a complaint through the public form is on a clock the moment it lands rather than the moment somebody opens the queue.
- A grievance officer published on the intake page, carrying the name, designation and contact details Rule 4(4) asks to be displayed, and owning what arrives through it.
- A resolution clock that runs straight through a pause for a chosen category, so a statutory month keeps counting while a conversation goes back and forth.
- Public intake selected per category, so the consumer complaint route and the general enquiry route can carry different deadlines behind one form.
Where we point you to a specialist
- We will not tell you whether these Rules reach your business. Rule 2 turns on whether you are an e-commerce entity within its meaning, and it extends to entities outside India that systematically offer goods or services to consumers in India. Whether that describes you is for your counsel, and a vendor answering it inside a settings screen would be selling a legal opinion with a checkbox on it.
- We will not let a configured target stand in for the rule. A due date in a help desk is a management target somebody typed; the period in Rule 4(5) runs whatever anybody typed. We will happily make the two agree, and we will keep saying they are different things — which is why the article above tells you to set the resolution target shorter than the period rather than equal to it.
The first of the four is a default and a setting, and it changes what happens on the day a complaint arrives. The second is a form field and a block on a page. The third is a flag read by the arithmetic that already exists. We would quote the set together and start with the first, because the other three improve a deadline that the first one is required for anybody to have.
See the help desk
Public intake without a login, acknowledgement and resolution targets per category on either kind of clock, anchored on receipt, with a breach check every fifteen minutes.
Explore the help deskFrequently asked questions
Does a ticket from your public complaint form get a deadline?
Not today, and it is the reason this article exists. A ticket raised on the public form is created without a category, and the acknowledgement and resolution targets are settings on the category — so both fields are empty and the breach check has nothing to measure. The workaround is real and it works: deadlines are anchored on the moment the ticket was created rather than the moment it was triaged, so assigning a category on Monday morning produces a deadline measured from when the complaint actually arrived. A default category for public intake is the first item in the buildable list above.
Which clock should a statutory deadline use?
The one that counts real elapsed time, which is our default. A period expressed in a rule as forty-eight hours from receipt is measuring calendar time and does not care whether your office was open. That is the opposite of the right answer for a contract worded "within one working day", which is why the choice is per category rather than per workspace — you will usually need both kinds in one system, and the two look identical until a weekend goes past.
Why does the acknowledgement clock behave differently from the resolution clock?
Because waiting on a requester pauses the resolution clock, and that pause is deliberately not applied to the first-response clock: a ticket cannot be waiting on somebody nobody has answered yet. That happens to be exactly the behaviour a forty-eight-hour acknowledgement period needs. The resolution side is the one to watch, because a rule that counts one month from receipt keeps counting while your system is paused, and both dates sit on the same screen looking equally official.
Can we publish a named grievance officer on the form?
Not as a field in the product yet — today that is a block you add to your own page beside the link to the form. What the product does have is a default assignee per category who is skipped automatically when they have left or been suspended, so tickets do not keep routing to somebody who will never see them. A published officer who owns what arrives through the public form is the second item in the buildable list.
How current is the rule you are quoting?
The Consumer Protection (E-Commerce) Rules, 2020 were notified as G.S.R. 462(E) on 23 July 2020 and came into force on publication. We could not reach the Department of Consumer Affairs' own site to read the gazette directly, so the wording here rests on two independent verbatim reproductions that agree word for word, plus several professional summaries — which is good, and it is not the same as reading the notification. Check the current text against the Department before you configure anything on the strength of this page, and take the applicability question to your counsel.
