A business-hours clock is a product-design constraint, not a decorative timer. The moment a help desk promises to measure response and resolution targets, every ticket needs a clear relationship to time: when the request entered the queue, when the operation was open, who owned the work, what counted as a response, and when the issue reached resolution. A clock that ignores the business calendar makes the rest of the workflow less credible.
Resolv is organized around that constraint. It is a complete help desk for a business that answers its own customers, with email and customer-portal requests entering a split-view inbox, teams and routing shaping ownership, and SLA targets measured against business hours. Saved replies, macros, automation, a knowledge base, CSAT and reporting extend the same operating model from intake to learning.
That description starts with the work rather than the screen. A support product can look like an inbox while leaving the actual process in the heads of the people using it. Resolv treats the queue as one part of a larger resolution system.
A message becomes accountable work
Email is an effective intake channel because customers already understand it. It is also an incomplete operating model. A mailbox can preserve a thread and a timestamp, but it does not automatically establish team ownership, response expectations, resolution status, reusable answers or the path from a completed conversation to operational feedback.
The customer portal presents the same distinction from another direction. A form can accept a request, yet intake alone says little about what happens next. The useful product boundary begins after submission, when the request has to enter a queue that somebody can understand and act on.
Resolv brings email and customer-portal requests into one ticket flow. Its split-view inbox keeps three important perspectives close together: the queue of work, the active conversation and the customer context surrounding that conversation. The arrangement is significant because support work constantly moves between those levels. An agent needs to understand one request without losing sight of the queue, and needs customer history without abandoning the exchange being handled.
The split view therefore expresses an operational idea. It reduces the distance between deciding what to work on and understanding the work itself. The queue is not merely a list of messages, and the conversation is not an isolated document.
Routing gives the queue a shape
Once a request becomes a ticket, the next question is ownership. Different requests call for different teams, and a support organization needs a stable way to express that division. Otherwise assignment becomes a repeated act of interpretation: somebody reads the ticket, decides where it belongs, finds the relevant person and communicates the transfer outside the system.
Resolv includes teams and routing as part of the ticket lifecycle. Saved ticket views add a complementary layer. Routing determines how work moves, while views preserve useful perspectives on the work that exists. Together they make the queue legible as an operation rather than a chronological pile.
This is also where the business-hours clock becomes practical. A response target has meaning only when a ticket is visible to the people responsible for meeting it. Timing without ownership produces an alarm. Ownership without timing produces an unmeasured queue. The product joins the two so a target can belong to an actual workflow.
Business time is different from elapsed time
Calendar time and service time are not interchangeable. A request that arrives after closing should not consume the same service window as one that arrives while the operation is staffed. Weekends and non-working hours introduce the same problem. If an SLA timer counts them without distinction, the reported breach may describe the calendar rather than the performance of the support organization.
Resolv includes an SLA engine with business-hours awareness and tracks both response and resolution targets. Those are different commitments. Response measures how quickly the operation acknowledges and begins handling a request. Resolution measures how long the issue remains open before reaching its completed state. Keeping both in the model prevents a quick first reply from standing in for actual completion.
Business-hours awareness makes those targets belong to the organization using them. The clock follows the period in which service is meant to happen. That design constraint reaches backward into intake and routing, and forward into reporting. A ticket needs reliable timestamps, an owner and a lifecycle before a response or resolution measure can mean much.
Context protects the quality of the reply
A timed operation can still be a poor one if speed separates the answer from the customer. Support conversations often depend on information established earlier: what the customer requested, which interactions preceded the current one, and what is already known about the relationship. Resolv places customer context beside the conversation in the agent inbox.
That placement keeps the product from treating every ticket as a fresh subject line. The agent can work within the active exchange while retaining access to the customer-level context that gives the exchange meaning. The queue, conversation and customer are separate concepts, but the interface does not force them into separate operating worlds.
Macros, canned responses and saved replies address another form of context: the organization's accumulated answers. Recurrent questions should not require recurrent invention. A reusable response preserves language that has already been prepared, while still leaving the current conversation visible. The goal is not to erase judgment; it is to keep routine wording from consuming the same effort every time.
Automation rules extend this principle from language to process. When a handling pattern is repeatable, it can become part of the help desk rather than a habit remembered by one person. In this model, automation supports the queue, routing and ticket lifecycle instead of existing as a separate collection of tricks.
Self-service belongs before intake
The most efficient ticket is sometimes the one that never needs to enter the queue. Resolv includes a published knowledge base that customers can search before writing in. It also includes an embeddable widget and a customer portal, giving the support operation multiple ways to place help close to the point where a question begins.
The knowledge base is connected conceptually to the conversation system. An answer discovered during support can remain useful after the original ticket closes when it is expressed as an article. Customers can search that material independently, while the portal and widget remain available when self-service is not enough.
This produces a clear sequence without forcing every question through the same channel. Search can answer a known question. The widget or portal can collect a request that needs attention. Email can remain a familiar path. Once a ticket exists, the same inbox, routing and timing model can take over.
Resolution should leave evidence
Closing a ticket is an operational event, but it is also a point at which the system can learn. Resolv includes CSAT surveys after resolution. The timing matters: satisfaction feedback is connected to a completed support interaction rather than floating as a general opinion with no ticket context.
Reporting and analytics provide the broader view. Individual conversations explain one customer's experience; reports reveal the shape of the operation across many tickets. Because Resolv also models response and resolution targets, the reporting surface sits downstream from a workflow that already knows about time, status and ownership.
The sequence is now complete. Intake creates the ticket. Routing gives it a destination. The SLA engine measures its response and resolution windows against business hours. Customer context and reusable responses support the conversation. Knowledge can prevent repeated intake. CSAT captures feedback after completion, and reporting makes the operation visible.
The API carries the lifecycle outward
A help desk often has to participate in processes that begin elsewhere. Resolv includes a public API for connecting other software and workflow endpoints that create, close and assign tickets in one call. These are not merely export surfaces. They expose actions that correspond to the central ticket lifecycle.
The choice of actions is revealing. Creation brings work into the system. Assignment gives it ownership. Closure records completion. Together they allow an external workflow to interact with the same operational sequence represented in the inbox.
This matters for a source-code product deployed on infrastructure controlled by its purchaser. The help desk can remain a coherent product while its core workflow is available to connected software. The API does not replace the agent experience, portal or knowledge base; it gives the surrounding system a direct way to participate in ticket movement.
A help desk defined by resolution
Resolv's product shape follows a simple distinction: receiving requests and resolving them are not the same job. A complete help desk has to preserve the accessibility of email and portal intake while adding the structure that messages alone do not provide. That structure includes a queue, ownership, business-aware time, customer context, repeatable answers, self-service, closure feedback and reporting.
The result is not a chronology of features bolted onto an inbox. It is a system in which each part clarifies the next. Business-hours targets make routing consequential. Routing makes the queue accountable. Context makes timed responses more useful. Knowledge reduces avoidable intake. CSAT and reports give resolution an afterlife as operational evidence.
For a closer look at how those pieces meet in the product, see Resolv →.