We built Resolve for ourselves first.
Before Resolve was a product, it was how we kept up with our own store's support queue. This is what it handles, how escalation works, and why we turned it into a product.
It started with our own queue
We run an e-commerce operation, and its support inbox is full of order queries, return requests, and refund questions, all day, every day. Answering them well took time the team didn't have; answering them fast meant quality slipped.
So we built Resolve to work the queue the way we would: read the ticket, check the order, apply the policy, reply. And when a case needed judgment, it handed the conversation to a person instead of guessing.
Order queries
Delivery estimates, shipping status, and address changes, answered from live order data.
Returns
Return requests checked against our policy, with clear next steps for the customer.
Refunds
Refunds applied by rule, and anything unusual routed to a person.
How escalation works
Resolve is built to know what it shouldn't handle.
Resolve answers what it knows
Tickets covered by our rules and knowledge base get resolved on the spot, on whichever channel they arrive.
Uncertainty goes to a person
Low-confidence and sensitive cases route to the team with the full conversation and a suggested next step.
Every handoff teaches it
We review escalations, correct what needs correcting, and fold the answer back into the rules.
Escalation view
The escalation view: conversations Resolve handed to a person, with full context attached. Sample data shown.
Then we made it a product
Once Resolve was working our own queue day to day, the path was clear: the rules engine, the channels, and the escalation flow work the same for any support operation. We packaged what we run ourselves. The product you see is the system we use.
Designed for queues like these
Resolve runs in production on our own retail operation. These are the kinds of queues its rules-and-escalation approach is designed for.
E-commerce and retail
Where we run it ourselvesHigh volumes of order queries, returns, and refunds, with peaks around sale seasons.
- Order status and delivery questions
- Returns and refund processing by policy
- Peak-season volume without temp staff
Subscription and SaaS
Billing and account questions where getting the policy right matters most.
- Billing and invoice queries
- Plan changes and cancellations by policy
- Feature questions answered from your docs
Travel and hospitality
Time-sensitive changes and demand that swings with the season.
- Booking changes and cancellations
- Seasonal spikes without seasonal hiring
- Multi-language conversations
Health and wellness
Queues where sensitive requests must reach a person.
- Appointment scheduling and reminders
- Routine questions answered from approved content
- Escalation-first handling for sensitive requests
See the system we run ourselves
Book a demo and we'll walk through Resolve using the kinds of tickets we handle on our own store.