The Business Day That Belongs to One Place
The business day in this product is two clock times and one application timezone. For a desk in Bengaluru promising a four-hour response to a customer in Lagos, the question of whose four hours those are has no answer here.
A deadline is a moment, and a moment is a time and a place. Systems that were built for one office get away with dropping the second half for years, because everyone who reads the number is standing in the same building.
What the business day is
Two clock times on the organisation — a start and an end — plus a working week and a holiday list. A ticket category can choose to have its deadline counted in working hours rather than in elapsed time, and when it does, this is the window it counts in.
Those times carry no zone. They are interpreted in the single timezone the application runs in, which is set once, in configuration, for everything.
Three things this cannot express
Follow-the-sun. Two teams in two regions covering one queue between them is the classic offshore arrangement, and the business day here is one window — so either it describes one team's hours and misrepresents the other's, or it is widened to cover both and stops meaning anything.
A deadline in the customer's day. "Four working hours" is a promise about the customer's working day at least as often as about yours, and when the two are five hours apart those are materially different promises.
A round-the-clock desk beside an office one. A support rota that runs seven days while the back office runs five cannot be expressed at all — and the mechanism that would allow it exists in the code, honoured by the workflow date service, with no screen anywhere to create one.
A four-hour response promised in one timezone and read in another is two different promises wearing the same number.
The choice that is actually available
The lever is the per-category clock, and it is more useful than it looks once you accept the zone constraint.
Your desk and your customers share a working day
Business hours
Correct, and it stops weekend false breaches. This is what the clock was built for.
Your desk is offshore from your customers
Elapsed
Honest. A wall-clock promise is a promise nobody has to translate, and it cannot be wrong about a working day it never claimed to model.
You run follow-the-sun
Elapsed, and mean it
A twenty-four-hour operation has no working day to count in. Business hours would be actively misleading.
Different customers, different expectations
Different categories
The clock is per category, so this is the one axis on which you genuinely can differentiate.
The general rule is that elapsed is the honest choice whenever the desk and the customer do not share a working day. It is a weaker promise and it is one the system can actually keep track of, which is worth more than a stronger promise measured against the wrong clock.
What is genuinely well built here
Two things, and they are worth saying because the constraint above is a real one and this page should not read as though the module is careless.
The working week is properly configurable, so a weekend that is not Saturday and Sunday is a supported setup rather than a workaround. And the pause behaviour is a remaining-time model rather than a refunded-span one: a ticket that waits on the requester gets back exactly the budget it had when it paused, measured on its own clock. An earlier version refunded a span of wall-clock time onto a working-hours deadline, which produced due dates at eleven at night on a category whose entire purpose was to only count working hours.
What AWRA OpsHub does today
- A configurable working week per workspace, including weekends that are not Saturday and Sunday.
- Business day start and end times per workspace.
- A per-category SLA clock — elapsed wall-clock, or the organisation's working hours.
- A pause that returns the remaining budget on resume, measured on the category's own clock.
- One working calendar service resolving leave arithmetic, workflow due dates and the SLA clock, replacing two answers that could previously disagree.
What it does not do
- Any timezone in the deadline arithmetic — not per agent, per customer, per branch or per country.
- More than one business-hours window per workspace.
- A support calendar distinct from the back-office calendar, though the mechanism exists in code with no way to create one.
- Follow-the-sun coverage as an expressible concept.
- Any deadline stated in the customer's working day rather than the organisation's.
Not ours, by choice
- One timezone is correct for the large majority of organisations using this product, and the constraint only bites where a desk and its customers are hours apart. That is a real shape of business and it is the one this page is written for.
- Elapsed being the honest choice offshore is a recommendation against our own more sophisticated feature. We would rather a customer used the clock that cannot lie to them.
- Nothing here is Indian. India is here because offshore desks serving distant customers are an ordinary business shape there, which is exactly what a single business-day window cannot describe.
What is not built for India today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in India. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an IRP connection, e-way bills, an Indian payroll engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
IRP registration, IRNs and e-way bills
Invoice registration against the IRP with the IRN and signed QR returned onto the document, e-way bill generation and cancellation for goods in movement, and the thirty-day reporting clock watched rather than discovered. Read the honest version first: this is the single most crowded build on this list. Tally, Zoho, Busy and a dozen others already do it, at a price we cannot approach, with a chartered accountant who already knows your ledger. We would build it to sit under an operations layer you had already chosen us for, not to win a GST comparison.
UPI, NEFT and bank feeds
UPI collection with automatic settlement against the invoice, NEFT and RTGS payment files, and bank statement feeds wired into the Payments Register so money in and out reconciles without re-keying.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Provident fund, ESI, professional tax by state and TDS on salary, computed on live records and produced in the return layouts each body expects. This is a serious statutory build with per-state variation, and it is a genuine reason to keep an Indian payroll provider rather than move payroll to us.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about time in a support system
Whose timezone is a deadline in?
A good answer sounds like
A specific one, and they know.
What it actually means
Ours is the application's. A vendor who has not thought about it will say "the user's", which is rarely true of the arithmetic.
How many business-hours windows can I define?
A good answer sounds like
One per team or region.
What it actually means
Ours is one per workspace. Ask before designing a rota around it.
What happens to a ticket raised at 02:00?
A good answer sounds like
A clear answer per clock.
What it actually means
On an elapsed clock it starts counting. On a working-hours clock it should start at opening — worth confirming rather than assuming.
Can I promise a customer their working hours?
A good answer sounds like
Only if the system models theirs.
What it actually means
Almost none do. Knowing that before you write it into an agreement is the whole value of asking.
Our position
If your desk and your customers are in different parts of the world, put those categories on the elapsed clock and write your commitments in elapsed hours. It is a weaker promise, it is honest, and it is one the numbers will support in a review. Reserve the working-hours clock for the queues where the desk and the customer genuinely share a day.
Ask whose hours the promise is in
Before an SLA goes into an agreement, settle which working day it is counted in and whether the system can model it. That conversation is cheap now and expensive at the first review.
Talk about offshore supportFrequently asked questions
Can I change the application timezone?
It is a configuration value for the deployment, so it is a deliberate decision rather than a per-user setting. Changing it moves every business-hours deadline in the product at once, which is why it is worth setting to your operating centre from the start.
Does the elapsed clock handle weekends?
It counts elapsed time and reads no calendar at all, so a ticket raised on Friday evening is halfway through its budget by Sunday. That is the trade — it cannot be wrong about a working day, because it never claimed to know about one.
What about a twenty-four-hour desk?
Use elapsed. There is no working day to count in, and setting business hours to midnight-to-midnight would produce the same numbers with a claim attached that the calendar could still contradict on a public holiday.
