Avo for customer support teams
Let support fix it, without a production console
Look up the customer, see their orders and subscription in one place, resend the receipt, apply the credit. All on the first reply, inside your Rails app, behind permissions you control.
250+ paying companies · 2.7M downloads of the avo gem
Order
number
status
total
User
name
signed_up_at
Subscription
plan
status
renews_on
Avo renders the associations your models already declare, so the agent opens the user and the whole story is already linked from it.
01 · the stakes
What answering a ticket actually costs today
Most support tickets end in a small change to production data. When support can't make that change safely, every ticket grows an engineering detour, and the customer waits on both teams.
-
01
The fix needs a console session
Resend a confirmation, unlock an account, correct a record: the agent knows exactly what to do and still has to ask an engineer to do it. The customer's two-minute problem takes a day, and an engineer context-switches for a one-liner.
-
02
Support access is all or nothing
A shared admin login that can see and edit everything is the fastest thing to set up and the scariest thing to keep. Support needs least privilege: see this, act on that, never touch the rest. That's exactly the part a hand-built admin skips.
-
03
The customer's story is scattered
Orders in the database, the subscription in the billing processor, tickets in the help desk. Agents tab-hop to reconstruct what happened, and the answer takes three tools before it takes one reply.
-
04
Support tooling never makes the sprint
Everyone agrees the support admin needs work, and it loses the priority fight every cycle because it doesn't ship features to customers. So the team keeps working around the tool instead of with it.
02 · the Avo version
Your models are already the hard part. Avo is the rest.
Avo mounts inside your Rails app and turns your existing models into the support console: the customer record with every related order, subscription, and event linked from it, the common fixes as one-click actions, and Pundit policies deciding exactly what each agent can see and do. And because the support console is the surface with the broadest read access in your company, the hardening around it is our job across hundreds of apps, not admin auth someone wrote in a hurry.
One page per customer, not five tabs
Avo renders your associations, so a user's orders, subscription, invoices, and activity hang off their record as linked panels. The agent opens one page and has the story, instead of reconstructing it across tools.
Your top ticket types, reduced to a button
Resend the confirmation, send a password reset, extend the trial, apply a credit: each is an Avo action with a confirmation step, calling the same model code your product uses. Support acts in seconds and nobody opens a console.
See this, act on that, never the rest
Avo reads your Pundit policies down to the field, so agents see what their role allows and sensitive fields simply don't render. The rules are Ruby in your repo, reviewed in a PR like everything else.
Find the right record fast
Search across every resource by what customers actually give you: email, order number, name. Then narrow with dynamic filters, and turn escalation queues like "refund requests older than a day" into saved views the team works down.
Every touch leaves a record
Pair Avo with model-level auditing and each fix records who did it and when, in your own database. When a customer asks what happened to their account, the answer is a lookup, not an investigation. Enterprise audit logging adds who viewed a record.
A User resource support can act on, with a field only admins see and a one-click fix:
class Avo::Resources::User < Avo::BaseResource
self.includes = [:orders, :subscription]
def fields
field :email, as: :text, readonly: true
field :name, as: :text
field :stripe_customer_id, as: :text, visible: -> { current_user.admin? }
field :orders, as: :has_many
field :subscription, as: :has_one
end
def actions
action Avo::Actions::ResendConfirmation
end
end
class Avo::Actions::ResendConfirmation < Avo::BaseAction
self.name = "Resend confirmation email"
def handle(query:, current_user:, **)
query.each { |user| user.send_confirmation_instructions }
succeed "Confirmation sent to #{query.count} user(s)"
end
end
03 · the timeline
From first resource to the team running on it
Generate resources for User, Order, and Subscription, and every customer already has a page with their history linked from it, on live production data.
Wire in the authentication you already have, write the support policy so agents see their slice and sensitive fields stay hidden, and ship the first action for your most common ticket.
The top five ticket types end with an agent clicking a button instead of pinging an engineer, every fix is logged, and first replies carry the fix instead of "we've escalated this".
case study · consumer platform
“Avo just worked great. We were able to plug things together really easily, and it's given us the flexibility we needed to build out a really rich product.”
04 · start today
Close tickets on the first reply, starting this week
Avo is per app with unlimited users, so the whole team works from it without the bill scaling with headcount. When you hit an edge Avo doesn't cover, you drop to plain Rails instead of filing a feature request.
Things customer support teams run from Avo
Avo for your team
Avo by industry
Frequently asked questions
- Can I build a customer support admin on Ruby on Rails?
- Yes. Your customers, orders, and subscriptions are already Rails models, and Avo turns them into a support console on top of your existing tables: one page per customer with everything linked, actions for the common fixes, policies for who can do what. It mounts inside your app, so there is nothing to sync.
- Do we have to replace Zendesk or Intercom?
- No. Keep the helpdesk where the conversations live. Avo is where the data lives and where the fix happens: the agent reads the ticket in the helpdesk, makes the change in Avo, and replies with it done. No migration, no new inbox.
- Can support fix customer problems without a production console?
- Yes. Each common fix becomes an Avo action: a button with a confirmation step that calls the same model method your product uses. Support gets a safe, logged way to act, and console access stays with the people who need it.
- How do we keep support from seeing sensitive fields?
- Your Pundit policies enforce access, the same ones your Rails app uses, down to individual fields. A payment identifier or internal note renders only for the roles you allow, and the rules live in Ruby you review like any other code.
- Can agents see a customer's full history in one place?
- Yes. Avo renders your Active Record associations as linked panels on the record, so orders, subscriptions, invoices, and events appear on the customer's page automatically. If the model relates to it, the agent can see it, as long as their permissions allow.
- Do we pay per support agent?
- No. Avo is priced per app with unlimited users, so the whole support team gets access and seasonal hires don't move the bill. Hosted admin tools typically price the other way.
- Does customer data leave our servers?
- No. Avo is a Rails engine mounted in your application, so every lookup and every fix is served by your app against your database. There is no third-party service between your support team and your customers' data.