What Restaurant Owners Really Need From Their Technology: Lessons From Customer Success

When a restaurant owner calls me, I don’t want my first thought to be:

“Which feature should I show them?”

I want it to be:

“What’s happening in your restaurant, and what are we trying to improve?”

Says Bedros Agopian, our Customer Success expert. 

Restaurant technology gets bought on features and judged on results. Before signing, owners ask what a system can do. Can it take online orders? Can it connect the delivery apps, manage the menu, and run reports?

A few months after go-live, the questions change. Is anyone ordering directly? Can the staff use this without the owner? What do these reports mean? Is this actually helping the business?

Bedros Agopian works on the other side of that shift. Bedros has spent 10 years in Customer Success, including more than five years working specifically with restaurants and F&B businesses. The job starts where the demo ends, once the technology is running inside the restaurant. Bedros calls the gap between the two sets of questions the difference between implementation and utilization.

What restaurant owners need from their technology is not the longest feature list. It is a system that gets used after it goes live. 

In years of Customer Success conversations with independent operators, Orders.co’s Bedros Agopian has seen value show up in four ways.

•  Staff can run the system without the owner. 
• Customers use the channels the restaurant wants to grow.
•  Repetitive work disappears. 
• The owner can measure the result.

This is not an argument for less technology. It is an argument for technology that gets used, works together, and does not depend on one person to run it. Bedros puts it in five words:

“A feature is not a result.”

About the expert	Bedros Agopian
Role	Customer Success, Orders.co
Customer Success experience	10 years
Restaurant and F&B experience	More than 5 years

What changes after a restaurant actually starts using its technology?

The question moves from capability to adoption. Before buying, the owner wants to know whether the restaurant can take online orders. About three months after go-live, Bedros says the question often becomes how to get more people to order online.

That is a different problem. Once the system is running, owners ask about repeat customers, loyalty, customer data, website traffic, employee usage, and reports. Underneath all of it sits one question: is this helping the business?

Buying a feature solves availability. It makes something possible. On its own, it does not change:

• Customer behavior. Customers keep ordering the way they already do until they have a reason to switch.
• Staff adoption. A system that the team works around saves no one any time.
• Marketing. A new ordering channel needs promotion before anyone uses it.
• Reporting. Numbers help only when someone knows what to do with them.
• Repeat business. A first order does not make a regular customer.
• Daily execution. The process has to hold up during a rush, not just in the demo.

What adoption looked like at Opa Cafe

Opa Cafe, a Mediterranean cafe in San Francisco, ran its online orders through several third-party tablets that kept failing. The failures caused missed orders, and the cafe had no ordering website of its own. Orders.co built a branded ordering website and brought the delivery providers into one system.

Opa Cafe reports a 70% increase in online orders since switching. The more useful number is how customers used the new channel. Between March 24, 2022, and July 24, 2026, the website took 11,862 orders. That was 52.8% of the cafe’s active online orders, more than DoorDash, Uber Eats, and Grubhub combined. The marketplaces stayed active and still carried 47.2% of orders.

This is one restaurant’s reported result, not an industry benchmark. It does show the progression Bedros describes. The website made direct ordering possible. Customers using it made it valuable.

The practical step is to plan for adoption before go-live. Decide who will promote the new channel, who will train the staff, and what number will show whether it is working.

Why doesn’t having a direct-ordering website automatically create direct orders?

A website makes direct ordering possible. It does not make it a habit. Customers who already order through DoorDash, Uber Eats, or Grubhub have practical reasons to stay where they are.

One question Bedros keeps hearing is how to get customers to order from the restaurant’s website instead of the apps. Most of the restaurants asking already have the tools: a website, online ordering, QR codes, loyalty, customer information, and marketing. Bedros sees the gap somewhere else:

“The real question is how to change customer behavior.”

Why customers keep ordering through the apps

According to Bedros, the reasons restaurants hear from their regulars are usually practical:

• They are already logged in to the app.
• Their payment details and address are already saved.
• They use the same app to order from other restaurants.
• They may pay for a subscription or membership.
• They may have found the restaurant through the app in the first place.
• Some do not know the restaurant has its own ordering website.

Bedros singles out the last reason. A restaurant can have a good ordering website and still miss direct orders because customers do not know it exists.

None of this makes the marketplaces the problem. As Bedros notes, third-party platforms still play a role in discovery and convenience. The goal is not to pull every customer off the apps. It is to make sure customers know there is another way to order from the restaurant, and to give them a reason to remember it.

Direct ordering is one customer journey, not five features

Bedros describes direct ordering as a sequence. The five stages below are Bedros’s. The tool mapping is ours, built from the tools Bedros names.

Stage	What needs to happen	Where the usual tools fit
1. Get discovered	New customers find the restaurant	Marketplaces, search, the restaurant’s website
2. Get the first order	A customer tries ordering directly once	QR codes, packaging inserts, and a first-order incentive
3. Capture the relationship	The restaurant can reach that customer again	A signup offer, loyalty signup, SMS, and email opt-in
4. Bring the customer back	The customer orders again	Loyalty rewards, SMS, email
5. Make the next order easier	Ordering directly feels as easy as the app	A fast ordering site, links that open straight to the menu

Seen one at a time, each tool can look like a feature that is not working. A QR code nobody scans. A loyalty program with few members. Seen as one journey, each tool has a job, and a weak stage shows where direct orders are being lost.

That points to a simple first step. Tell customers the website exists, everywhere they already meet the restaurant. Then give them one good reason to try it.

What do owners start worrying about once the demo is over?

Who will run it? Bedros says one question stands out in the first week after go-live. It rarely comes up in the demo: what happens when I’m not here?

During a demo, the owner is checking the capability. Once the restaurant is operating, the questions turn to people. Bedros describes the shift like this:

What owners ask in the demo	What they ask once it is running
Can it take orders?	Who checks the orders?
Can I manage my menu?	Who changes the menu?
Can I have a website?	Who manages the website?
Can it connect to my delivery services?	Who knows what to do if something stops working?

Two more come up often: who looks at the reports, and who handles all of it when the owner is on vacation.

The operation should not depend on one person

Bedros’s answer is direct. A restaurant should be able to manage orders, pull reports, run the POS, and make routine menu or website updates. None of that should wait for the owner or one specific employee.

Bedros has seen situations where one person becomes the only one who knows the system, and everyone else waits on them. Bedros calls that dangerous for the business. The standard to aim for is simple:

“Good technology should turn individual knowledge into an organizational process.”

In practice, that often starts with the owner. The owner handles a task first, such as a menu change or a weekly review of the reports. Then a process gets set up so a manager or employee can take it over. The goal is not to make the owner the expert. It is to make the knowledge transferable.

That matters on an ordinary shift, not only during a vacation. Staff change. Schedules change. A menu update that only one person can make is a menu update that waits.

Fewer systems to watch means less that depends on the owner

Alfredo’s of Summersville, an Italian and Greek family restaurant in West Virginia, is one example. Before Orders.co, it had no ordering website of its own. Online orders arrived on a separate tablet for each platform, and keeping up with them pulled the owner’s attention away from the business.

Onboarding took two days. With orders in one system, the restaurant’s customer story describes an owner no longer tied to managing tablets day to day. Alfredo’s has also reported roughly 12 to 15% revenue growth in its first month and now runs two locations, with a third in progress. These are one restaurant’s customer-reported results, and the growth figure is approximate.

Bedros suggests every restaurant ask one question earlier than most do. If the owner were unavailable tomorrow, could someone else run this part of the business? Good technology helps the answer be yes.

Should restaurant technology reduce the owner’s workload or add to it?

It should reduce it. Bedros applies one test to any fix proposed to a restaurant owner:

“If my solution is to give the owner another five things to remember every week, I haven’t really solved the problem.”

Customer marketing shows how the test works. Bedros does not ask an owner to build a customer list by hand. The starting point is customer information that the restaurant already has, such as an export from Toast. The restaurant already has the customers. The job is to turn that information into marketing activity without adding a weekly chore.

The same principle applies to automated SMS and email, loyalty, QR campaigns, and re-engagement. In Bedros’s view:

• If a regular stops ordering, the owner should not have to notice and follow up by hand.
• If a customer has already ordered, the restaurant should not have to rebuild that customer’s record every time it markets to them.
• If the restaurant wants more direct orders, it should not have to explain the website to every customer one at a time.

Automation has to earn its place by removing tasks like these.

The better question about AI

Conversations about restaurant technology often turn to AI. Bedros thinks there is a better question to ask. It is not about how to give restaurants more AI. It is this:

“Which repetitive parts of running the restaurant should technology take off the owner’s plate?”

That question puts the work first. AI is not the story. Less repetitive work is. An AI feature that adds a new weekly review step fails the test. A plain automation that sends the right reminder without anyone touching it passes.

A manual check that became an alert at Bagels and Beyond Cafe

Bagels and Beyond Cafe ran multiple brands from a stack of separate tablets. On top of that, owner Karim Mohamed checked for chargebacks by hand. Chargebacks are the charges a delivery app passes back to a restaurant when a customer reports a problem with an order.

With Orders.co, the four-person team moved every brand and delivery platform onto one system and turned on automatic chargeback alerts. The restaurant’s customer story reports fewer devices, lower costs, no more missed orders, and management time freed up for growing the business.

That is one restaurant’s experience, not a typical result. It is also a clear example of the standard Bedros uses. A recurring manual check became an alert. The owner did not get another task. One went away.

Before adding any tool, ask what recurring task it removes. If the answer is none, it is probably adding one.

Where should the restaurant’s responsibility end and the technology provider’s begin?

The restaurant owns normal operations. The provider owns genuine technical problems. Bedros thinks that line should be very clear. When it blurs, the restaurant ends up doing the provider’s job.

Normal operations: the restaurant handles	Technical problems: the provider owns
Changing a menu item or a price	Information appearing incorrectly on the website
Managing orders during service	Orders not reaching the restaurant correctly, including across locations
Running a promotion	Integration and development issues
Training employees and reviewing normal reports	Hardware problems

The first two problems in the right column come from situations Bedros has seen with customers. Neither should be the restaurant’s to fix.

“The restaurant shouldn’t have to become a technical support department.”

The left column matters just as much. In Bedros’s view, a restaurant should not need a technical expert every time it makes a normal business change. If a price update needs a support ticket, the system has put routine work in the wrong place.

What good support sounds like when something breaks

Bedros describes the right response to a genuine technical problem in three parts. The provider has identified the issue. It has identified who owns the fix. And it tells the restaurant what happens next.

That is where Customer Success becomes more than answering questions. It becomes coordination. The owner keeps running the restaurant while the provider runs down the problem.

The cost of a blurry line is real. Part of why Opa Cafe left its previous provider was that help did not arrive fast enough, while orders were going missing.

Before signing with any provider, ask three questions:

1. Who owns an integration failure during service?
2. How will the restaurant hear that someone is working on it?
3. Who coordinates the fix when more than one company is involved?

What has working with restaurant owners changed about the way Bedros thinks about technology?

It changed where the conversation starts. Bedros says the biggest lesson from restaurant customers has been this: “A feature is not a result.”

A restaurant can have the tool and still miss the outcome:

• It can have a QR code that customers never scan.
• It can have a website that brings in a few direct orders.
• It can collect customer data and never use it.
• It can have AI marketing and not know what campaign to run.
• It can receive reports and not know what action to take.

Owners are pushing the conversation the same way. Bedros hears fewer questions about whether a feature exists and more about what it is doing for the business. Owners want to know what is happening, how it works, and what to do with the information. One owner already received marketing reports but wanted to understand how the system worked and what the numbers meant. Bedros is careful not to treat one question as proof of a trend. Similar questions keep coming up across conversations, and that is the pattern worth noting.

The lesson also changed how Bedros starts a call. The first thought is no longer which feature to show. It is what is happening in the restaurant, and what the owner is trying to improve. Once the problem is clear, the technology gets much easier to explain.

How a guest list became a marketing plan

Bedros saw the difference with one customer, Rod. The conversation about AI marketing became useful once it connected to something Rod already had: a customer and guest list in Toast. Instead of presenting another marketing tool, the conversation turned to five questions:

1. What customer information do you already have?
2. How can we use it?
3. What should we send?
4. How do we get customers to take action?
5. How do we know whether it worked?

Those questions move the conversation from feature to activity to outcome. The feature is the marketing tool. The activity is a specific message sent to a specific list. The outcome is customers ordering again, and a way to check that it happened.

So how should a restaurant judge whether its technology is actually working?

Judge it by what changed after go-live, not by what it can do. Restaurant technology is working when five things are true. It improves the result that the restaurant can measure. Staff use it. Someone besides the owner can run it. It removes recurring work. And when something technical breaks, the provider clearly owns the fix.

The five-question restaurant technology test

This test is an Orders.co takeaway from the interview. It turns the patterns Bedros describes into five questions an owner can ask about any system.

Question	A good answer	A warning sign
1. What result should this improve, and how will we measure it?	One named number, such as direct orders, repeat customers, or missed orders, is checked on a schedule	The only answer is the feature list
2. Are staff using it now that it is live?	The team uses it during service without calling the owner	Staff work around it, or one person does everything in it
3. Could someone besides the owner run it tomorrow?	A manager can change the menu, check orders, and pull reports	Routine changes wait for the owner
4. What recurring manual work does it remove?	A task that used to happen by hand now happens on its own	It adds a new weekly checklist
5. When something technical breaks, is it clear who owns the fix?	The provider names the issue, who owns the fix, and the next step	The restaurant relays messages between support teams

What is the real measure of restaurant technology?

Not the length of its feature list. Owners buy on what a system can do, then judge it on what changes after go-live. A restaurant can have online ordering, loyalty, customer data, automated marketing, reports, and a POS, and still get little from any of them.

The difference is in use. Staff who run the system without the owner. Customers who order differently because of it. Work that stops landing on the owner’s desk. A result the owner can point to.

The answer is rarely less technology. It is technology that gets used. After 10 years in Customer Success, this is the lesson Bedros keeps coming back to:

“Don’t measure technology by how many features a restaurant has. Measure it by how much easier it makes the restaurant’s business to operate, grow, delegate, and serve its customers.”

If you’re evaluating restaurant technology, the feature list is only the beginning. See how Orders.co approaches onboarding, connected operations, and ongoing Customer Success.

How we developed this article

This article is based primarily on a structured interview with Bedros Agopian of Orders.co Customer Success. It draws on Bedros’s 10 years in Customer Success, including more than five years working with restaurants and F&B businesses.

Bedros’s observations reflect recurring themes from customer conversations, not a statistically representative survey of restaurant operators. Bedros notes that not every conversation has been captured in a standardized research database. Descriptions of what owners ask are Bedros’s summaries of those conversations, not verbatim customer quotes.

Customer examples come from Orders.co customer stories. Figures described as reported come from the restaurants themselves.

The five-question test is an Orders.co editorial framework built from the interview. The article does not rely on outside industry statistics.