Response times
The three clocks on every Conversation, the first answer, a reply from a person and any intake deadline, and the Settings and terms that hold them.
Every Customer knows how fast the Startup answers before they ask. Three clocks run on every Conversation: the first answer, a reply from a person, and any legal intake deadline.
Three clocks
| Clock | Setting | Default | Starts at | Recorded as |
|---|---|---|---|---|
| First answer | support.firstResponseWithin | 4 business hours | The Conversation's first Message | respondBy, then firstAnsweredAt |
| A person replies | support.humanReplyWithin | 1 business day | The request for a person | The due time of a Task for a Human |
| Intake deadline | The intake's own deadline | 3 days to 10 business days | The Conversation's first Message | The intake's Thread |
Hours count on the Startup's own business-hours calendar. A Message that arrives after hours starts its clock when the next working day opens.
Settings hold the numbers
Each clock reads a Setting, held per Offer and inherited down from the Studio. A child may only tighten: an Offer may promise 1 business hour for a first answer, never 8.
The terms of service state both support numbers for each Offer, read from the same Settings. The first automatic acknowledgment repeats them, so the Customer never guesses.
A Service Offer can also promise an outcome and uptime in its service-level terms. Those bind the delivered work; the three clocks bind every answer, on every Offer.
The first answer
Every Conversation gets respondBy when its first Message arrives, counted from the Offer's Setting on the business-hours calendar. The Customer Lead answers before then through Answer a message.
firstAnsweredAt records the first answer once and is never overwritten; answeredAt keeps the latest. A quick follow-up question cannot make a slow first answer look fast.
Reaching a person
A request for a person always reaches one. The support Agent stops answering the substance and opens a Task for a Human, due by support.humanReplyWithin, with a summary of the Conversation attached.
The Task goes to the Startup's own Human when it has one. Otherwise it goes to the owner of record of the Startup's Company. For a Studio Startup that is the officer desk; for a self-serve one, the person who holds its Stripe account.
The Customer hears the due time in the next answer. A Task past due escalates through Task.escalate, and the overdue Task is the record of the miss. No other work waits on the Human: the Agent keeps answering every other Conversation.
Intakes keep their own deadline
A privacy request, legal notice or security report can arrive as an ordinary support Conversation. The support Agent matches it to its intake, opens that intake's Thread at its address, and links the Conversation.
The intake deadline counts from the Conversation's first Message, not from the handover. The owning Role answers in the intake's Thread, and the Customer hears in the Conversation who holds the request and by when.
What the Startup measures
| Metric | What it reads |
|---|---|
| First response time | Median business hours from the first Message to firstAnsweredAt |
| First responses on time | Conversations first answered before respondBy, as a percent |
| Intakes answered on time | Intake Threads, opened at the address or from a Conversation, answered before their deadline, as a percent |
| Resolution time | Median business hours from the first Message to a resolution that held for 7 days |
A meal-planning app for households managing diabetes promises a first answer within 2 business hours. A parent writes after hours asking for a person. The Agent answers at once with the next morning's due time, and the Founder replies at 9:40.
Next
- Answers: what every answer checks before it is sent.
- Customer guarantees: the promises these clocks keep.
- Intakes: the eight addresses and their deadlines.