Avo for operations teams
Give your ops team a command center, not a ticket queue
Orders, approvals, and exceptions, worked from saved views with bulk actions the ops team runs without help. No ticket, no console session, no waiting on the engineering backlog.
250+ paying companies · 2.7M downloads of the avo gem
08:52 · open the saved view
31 orders match the filter
08:54 · select all
every matching record, not just the visible page
08:55 · run Mark as shipped
one confirmation step, one code path
08:55 · logged
each change recorded with the acting user
A queue that used to be a ticket thread is cleared before standup, and every change carries who ran it.
01 · the stakes
Why ops always ends up waiting on engineering
Operations runs on production data, but the tools to act on it belong to engineering. Every gap between the two turns into a ticket, a spreadsheet, or a console command someone has to be trusted with.
-
01
Every routine fix is an engineering ticket
Reassigning records, correcting a batch of statuses, closing out stale entries: nobody understands this work better than the ops team, and all of it still routes through a developer with console access. A two-minute fix waits two days.
-
02
Spreadsheets become the real system
When the tooling can't keep up, the team exports to a sheet, edits there, and pastes results back. Now there are two sources of truth, and the one people actually work from is the one with no permissions and no history.
-
03
The homegrown admin covers last year's happy path
The internal tool handles the cases it was built for. Every feature shipped since then arrived without any tooling at all, and the queue of "can you add a button for this" requests never makes the sprint.
-
04
Hosted tools charge by the head and sit in your data path
Putting the whole ops team into a hosted admin builder means a bill that scales with headcount and production data flowing through a vendor. The bigger the team, the worse both problems get.
02 · the Avo version
Your models are already the hard part. Avo is the rest.
Avo mounts inside your Rails app as an engine, so it works directly on the models and data you already have. Approve, reassign, close out: the things your ops team does all day become actions they run themselves, and the lists they check every morning become saved views. Pricing is per app with unlimited users, so the whole team gets access without a per-seat bill.
The whole queue, handled at once
Filter to the records that need attention and select all of them. Selection means every record matching the filter, not just the page you can see. Then run an action: update statuses, reassign owners, close out a batch. What used to be a console session is a button with a confirmation step.
Work that moves through stages, on a board
Some processes have a pipeline shape: onboarding, fulfillment, review. For those, kanban boards put records in columns the team drags between stages, backed by the same models and permissions as the rest of the admin.
Morning queues as saved views
Unfulfilled orders older than two days, refund requests pending review, records flagged for follow-up: scopes and dynamic filters turn each list into a link the team opens and works down, without writing a query.
Approvals with a paper trail
An approval becomes an action with a confirmation step and a required reason, running one code path you wrote. Pair it with model-level auditing and every decision records who made it and why, in your own database.
A big team, narrow access
Avo reads your Pundit policies down to the field and the action, so a seasonal hire can work the fulfillment queue without seeing customer payment details. Giving twenty people access to production data stops being a decision anyone loses sleep over.
An Order resource with a bulk fulfillment action:
class Avo::Resources::Order < Avo::BaseResource
self.includes = [:customer]
def fields
field :number, as: :text, readonly: true
field :status, as: :select, enum: ::Order.statuses
field :customer, as: :belongs_to
field :shipped_at, as: :date_time
end
def actions
action Avo::Actions::MarkAsShipped
end
end
class Avo::Actions::MarkAsShipped < Avo::BaseAction
self.name = "Mark as shipped"
def fields
field :note, as: :textarea
end
def handle(query:, fields:, current_user:, **)
query.each { |order| order.ship!(note: fields[:note], by: current_user) }
succeed "Marked #{query.count} order(s) as shipped"
end
end
03 · the timeline
From first resource to the team running on it
Generate resources for Order, Customer, and Shipment, and you have a navigable admin on real production data, with related records linked from each other.
Put it behind your existing authentication, write Pundit policies so each role sees its slice, and ship the first bulk action so the most common console request becomes a button.
The morning queues are saved views the team works down without help, approvals leave a trail, and the ops section of the engineering backlog stops growing.
case study · rental ops · two developers serving a 30+ person company
“Having Avo is like having this extra pair of hands... Every time you use it, you save time.”
04 · start today
Get ops off the engineering backlog 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 operations teams run from Avo
Avo for your team
Avo by industry
Frequently asked questions
- Can I build internal tools for an operations team on Ruby on Rails?
- Yes. The records ops works with are ordinary Rails models, and Avo turns them into a working internal tool on top of your existing tables: resources for the records, actions for the operations, saved views for the queues. Because Avo mounts inside your Rails app as an engine, there is no separate system to build or sync.
- Can the ops team run bulk updates without a developer?
- Yes. Avo's actions run on a selection, including every record matching the current filter, not just the visible page. Updating a whole filtered queue becomes: filter, select all, run the action, confirm. And because the action is Ruby you wrote, a large batch can enqueue a background job instead of blocking the request.
- How do we keep an audit trail of what ops changed?
- Pair Avo with model-level auditing and every change is recorded with the acting user, in tables in your own database you can query anytime. Actions can also require a reason, so approvals and corrections carry their justification with them. Avo's audit logging goes further on Enterprise, down to who viewed a record.
- Do we pay per seat for a large ops team?
- No. Avo is priced per app with unlimited users, so the whole operations team works from it and the bill does not move when the team grows. That is the opposite of hosted admin builders, where the bill moves with headcount.
- What happens when we need a workflow Avo doesn't cover?
- You drop to plain Rails. Avo is a Rails engine, so custom pages, custom fields, and custom tools are Ruby and ERB in your codebase, not feature requests on a vendor's roadmap. The conventional parts stay conventional; the unusual ones are normal Rails work.
- Does our production data pass through a third party?
- No. Avo runs inside your application on your servers, reading and writing your database directly. There is no hosted platform in the path, which matters both for security review and for latency on the bulk work ops does all day.