Skip to content

BA Assist — Support SLA

Status: Draft v0.1 · Owner: Manish Yadav · Effective from: to confirm Applies to: Production support for client-reported issues in BA Assist.

Table of contents

1. Purpose and scope

This document defines the support commitments for BA Assist: how a client raises an issue, how quickly we acknowledge it, how quickly a person responds, and what we aim for on resolution.

In scope: defects, errors and service disruption in the BA Assist production application.

Out of scope: see section 10.

This is a support SLA, not an availability SLA

This document commits to how we respond to issues. It does not commit to a percentage uptime figure. Availability targets require monitoring and recovery testing that are not yet in place — see section 13.

2. Key definitions

Read this section first. These four distinctions carry the whole document.

Availability vs. support coverage

Term Meaning For BA Assist
Availability When the application is running Intended to be available 24/7. No committed availability SLA yet — see section 13
Support coverage When a person is on duty to act on issues 2:00 PM – 11:00 PM IST, Monday to Friday

These are independent. The application is intended to run overnight; the support team does not. A client can raise a ticket at any hour — it is simply actioned when coverage next begins.

Note that "intended to be available 24/7" is a statement of design, not a commitment. We do not currently publish an uptime percentage, and we will not until monitoring and recovery testing are in place.

The three clocks

Every ticket has three separate measurements. Confusing them is the most common cause of disputes.

Clock What it means Committed?
Acknowledgement We confirm we have received the issue Yes — committed
Response A person has triaged it and told the client what is happening Yes — committed
Resolution The issue is fixed, or a workaround is in place Target only, not guaranteed

Never commit to a resolution time in writing to a client

Resolution depends on root cause, which is unknown when the ticket arrives. Commit to acknowledgement and response; give resolution as a target and keep the client updated. This distinction protects both the team and the client relationship.

Coverage hours vs. calendar hours

All targets in this document are measured in coverage hours — time inside the support window — not wall-clock hours.

An issue raised at 10:30 PM IST with a 2-hour response target is due at 3:30 PM the next working day, not at 12:30 AM.

The arithmetic: 30 minutes remain in the window on the day it was raised (10:30 PM to 11:00 PM), leaving 90 minutes to run from 2:00 PM the next working day — which lands at 3:30 PM. Further worked examples are in section 3.

Target vs. guarantee

  • Committed — we are accountable for meeting it, and misses are reported.
  • Target — our genuine aim, reported against, but dependent on factors outside our control.

3. Support coverage window

Coverage: 2:00 PM – 11:00 PM IST, Monday to Friday, excluding public holidays.

Timezone Window Notes
IST (UTC+5:30) 2:00 PM – 11:00 PM Authoritative — the SLA is defined in IST
US Eastern (summer, EDT) 4:30 AM – 1:30 PM Informational
US Eastern (winter, EST) 3:30 AM – 12:30 PM Informational
UTC 08:30 – 17:30 Informational

Why the SLA is written in IST

US clocks change for daylight saving and Indian clocks do not, so the window shifts by an hour in the client's local time twice a year. Defining the SLA in IST keeps the team's obligation fixed and avoids a dispute every March and November. Always quote the client's local equivalent as informational.

Official intake channel

To be agreed before this SLA takes effect

The official channel has not yet been agreed. Once it is, record it in the table below and confirm it to the client in writing. Until that happens, the targets in this document cannot be measured reliably, because there is no single place where the start time is recorded.
Official channel To be agreed — a dedicated support mailbox or ticket queue
Backup channel To be agreed — used only if the primary channel is unavailable
Not covered Direct email to an individual, chat message, or a verbal report in a meeting

An issue reported through an uncovered route is not ignored. It is logged into the official channel first, and the clock starts from the moment it is logged — not from the original conversation.

What starts the SLA clock

The clock starts at the later of these two moments:

  1. The issue arrives through the official intake channel, and
  2. The coverage window is open.

The clock pauses when we have asked the client for information we need in order to proceed, and resumes when they reply. Any pause is recorded on the ticket with the time and the reason.

The clock stops at the point the relevant target is met — acknowledgement when we confirm receipt, response when a person has triaged and replied.

Raising issues outside the window

Clients may raise an issue at any time, on any day. Issues raised outside the coverage window are queued and the SLA clock starts at the next window opening.

Worked examples

Issue raised Clock starts S1 response due (2 coverage hours)
Tuesday 4:00 PM IST Immediately Tuesday 6:00 PM
Tuesday 10:30 PM IST Immediately Wednesday 3:30 PM (30 min Tue + 90 min Wed)
Wednesday 1:00 AM IST Wednesday 2:00 PM Wednesday 4:00 PM
Friday 11:30 PM IST Monday 2:00 PM Monday 4:00 PM
Saturday, any time Monday 2:00 PM Monday 4:00 PM

State this explicitly to the client

An issue raised at 6:00 PM ET on Friday will not receive a human response until Monday afternoon IST. This is a direct consequence of the coverage window and must be agreed with the client in advance, not explained after the fact.

4. Support model and points of contact

Model

BA Assist support currently operates as L3 only. There is no L1 helpdesk and no L2 tier. The engineers who diagnose an issue are the same people who fix it.

Tier Normally does Our position
L1 Takes the call, logs the ticket, handles known answers Not staffed
L2 Standard triage, applies known fixes Not staffed
L3 Root-cause analysis, code fixes, deployment This is us

What this means for the targets

The two people covering support are also the people building the product. Response targets in section 6 are set with that in mind. If an L1 or L2 tier is introduced later, acknowledgement and response times can be tightened.

Points of contact

Role Person Responsibility
Primary contact Manish Yadav First responder; triage, fix, client updates
Secondary contact Yashawini Paramasivan Cover when primary is unavailable
Application owner Manish Yadav Accountable for production changes

Interim arrangement

Two named people covering a nine-hour window is workable at the current client volume, but both are also full-time on delivery. This arrangement should be reviewed when client count grows or when coverage hours are extended — see section 12.

5. Severity levels

Severity is set by impact, not by how urgently it is reported. The support contact assigns it at triage and records the reason.

S1 — Critical

Service is unusable for all or most users, or data is at risk.

BA Assist examples

  • No user can sign in
  • The application is unreachable
  • Meeting bots are failing to join across all meetings
  • Suspected data loss or data exposure

S2 — High

A core feature is broken for multiple users. The product is usable but a main workflow is not.

BA Assist examples

  • Meeting notes or summaries are not being generated
  • The live coverage / copilot panel is not updating for anyone
  • Document or video uploads fail for all users
  • Notification emails are not being delivered

S3 — Medium

One user, one meeting or one project is affected, and a workaround exists.

BA Assist examples

  • Notes failed for a single meeting and can be regenerated
  • One user cannot access a specific project
  • An integration sync failed for one item
  • Incorrect content in a generated document

S4 — Low

Cosmetic issues, minor defects and change requests.

BA Assist examples

  • Layout or wording issues
  • A label or date format is wrong
  • Feature requests and enhancements

6. Response and resolution targets

All times are in coverage hours (section 2). "Business day" means a day with a coverage window.

Severity Acknowledgement Response Target resolution or workaround
S1 30 minutes 2 coverage hours Same or next coverage day; workaround prioritised over full fix
S2 1 coverage hour 4 coverage hours 3 business days
S3 4 coverage hours 1 business day 10 business days, or the next scheduled release
S4 1 business day 3 business days Backlog — no committed date

Committed: acknowledgement and response. Target: resolution.

Why resolution is a target

An S1 caused by a third-party outage cannot be resolved by us at all — only escalated and communicated. See section 10.

7. Acknowledgement commitment

Acknowledgement is given by a person, within the coverage window.

A named contact confirms they have the issue, states the assigned severity, and gives the time of the next update. Timings are in section 6.

Automated acknowledgement is not yet in place

An immediate automated confirmation of receipt, sent at any hour, would let us confirm receipt outside the coverage window. This is not currently configured, so it is deliberately not claimed here. It is tracked in section 13 and will be added to this document once it is set up and verified working.

Rules for acknowledgement messages

  • Never state or imply a fix time before triage is complete.
  • Never speculate on cause in the first message.
  • Always give a next-update time, and meet it — even if the update is "no change yet".

Ready-to-use wording is on the Client Response Templates page.

8. Communication and status updates

Meeting the update cadence matters more than resolving quickly. A client with a broken feature and regular honest updates escalates far less often than one left in silence.

Severity Update frequency Channel
S1 Every 2 coverage hours until resolved Email plus agreed channel
S2 Once per coverage day Email
S3 On status change, or weekly Ticket
S4 On closure Ticket

Every update states: what we know, what we are doing, what we need from the client (if anything), and when the next update will arrive.

9. Escalation path

Step Trigger Goes to
1 Issue raised Primary contact
2 Primary unavailable, or no response within target Secondary contact
3 S1 open beyond one coverage day, or client dissatisfied Delivery manager
4 Root cause is a third-party service Vendor support, client informed in parallel
5 Root cause is database, backup or AWS account level Infra POD owner

Escalation contacts

Every role below must resolve to a named person with a contact method before this SLA takes effect. A role with no name is an escalation path that fails at the moment it is needed.

Role Name Contact Status
Primary contact Manish Yadav internal directory Confirmed
Secondary contact Yashawini Paramasivan internal directory Confirmed
Delivery manager To be confirmed — Needed
Infra POD owner To be confirmed — Needed
Vendor — meeting capture / transcription To be confirmed Support portal and account reference needed Needed
Vendor — cloud platform To be confirmed Support plan level needs confirming Needed

Four contacts are still outstanding

Delivery manager, Infra POD owner and both vendor escalation routes are not yet filled in. The Infra POD contact is the most urgent of the four, because it is also the only route to a database restore — see section 13.

Separate the fixer from the communicator

For an S1, whoever is diagnosing should not also be managing client updates. Escalate to the delivery manager for communication so the investigation continues uninterrupted.

10. Exclusions

The following are not covered by the response and resolution targets above. They are still acknowledged, triaged and communicated.

Exclusion Why Example
Third-party service outages Outside our control; bound by the vendor's own SLA Meeting bot provider is down, so no bot joins
Cloud platform incidents Outside our control AWS regional service disruption
Client-side configuration Not our system Expired credentials for the client's Jira or Azure DevOps
Client network or device issues Not our system Corporate firewall blocking the application
Enhancement requests Not a defect "Can it also export to PowerPoint?"
Issues in non-production environments Not production support A defect found in a demo stage
Use outside documented functionality Not a defect Uploading an unsupported file format

Our SLA cannot exceed our vendors' SLAs

BA Assist depends on external services for meeting capture, transcription, AI generation, authentication and email. If one of these fails, we can escalate and communicate but we cannot resolve. Any commitment made to a client is bounded by these dependencies.

11. Leave and absence cover

  • Planned leave — the other named contact covers. Notify the client in advance if the primary will be away for more than two consecutive coverage days.
  • Both contacts unavailable — coverage must be announced to the client in advance, with the alternative arrangement stated. Coverage must never silently lapse.
  • Unplanned absence — the remaining contact covers, and the delivery manager is informed the same day.

Single point of failure

With only two named contacts, any overlap in leave leaves the window uncovered. Leave should be coordinated between the two contacts before it is booked.

12. Review and reporting

Monthly, the support contacts report:

  • Number of issues by severity
  • Acknowledgement and response times against target
  • Any missed targets, with the reason
  • Recurring issues that should become backlog items

This SLA is reviewed after the first three months of operation, and whenever client count changes materially, coverage hours change, or an additional support tier is introduced.

13. Current constraints

Recorded honestly so that commitments are made with full knowledge. These are active improvement items, not reasons to delay the SLA.

Constraint Effect on this SLA
No alerting is currently delivered to a person Issues are detected when a client reports them. Acknowledgement and response clocks are reliable; proactive detection is not yet available.
No recovery time has been measured No recovery-time or uptime commitment can be made until a restore has been performed and timed.
Database backups are owned by the Infra POD Backup and restore commitments require confirmation from the infrastructure owner before they can be published.
Two named contacts only Coverage depends on two individuals; leave must be coordinated.
Automated acknowledgement is not configured Receipt cannot be confirmed outside the coverage window. Once configured and verified, section 7 is updated to claim it.
Official intake channel not yet agreed Start times are not recorded consistently, so targets cannot be measured reliably until it is agreed.
Escalation contacts incomplete Delivery, Infra POD and vendor routes are unnamed; escalation would stall at the point it is needed.
Support and delivery are the same people Sustained S1 activity will displace feature work. Extended incidents should be flagged to the delivery manager.

What would allow tighter commitments

Wiring existing alarms to a monitored channel would enable proactive detection and a genuine time-to-detect figure. Performing and timing a database restore would enable a recovery-time commitment. Both are tracked as readiness items.