Results as a Service: the kiosk under the tablecloth

By Joby Thuruthel, Creative Technologist, FAIM Digital W.L.L

On the second morning of the conference, somebody threw a tablecloth over the kiosk.

It was a sensible thing to do. The screen had frozen the afternoon before, the hall was filling up, and a grey screen with a spinning wheel looks worse than no screen at all. So a coordinator found a spare white cloth from the catering store, draped it over the unit, and taped a printed arrow to it pointing at the human desk.

The operations head of the conference organiser told us this story in our first call, a few months later. She was not angry about the freeze. Things break. What bothered her was the invoice that arrived three weeks afterwards, for three days of kiosk rental, in full.

She had paid for a screen, she said. What she had wanted was delegates checked in.

That is the whole idea of Results as a Service, said by somebody who had never heard the phrase.

What Results as a Service means

For twenty years most business software has been sold the same way. You pay for access, usually per seat per month, and then your own people do the work to get value out of it. If nobody logs in, you still pay. If it sits under a tablecloth, you still pay.

Results as a Service turns that around. ChatCenter puts it in one line: “In a SaaS model, the customer pays to use a tool. In RaaS, the customer pays for a result.” The growth agency Fornelli by Design is stricter about it, describing a model where “fees are tied directly to an objectively measured business outcome.”

There is a middle step that is easy to miss. Between paying for a seat and paying for a result there is paying for a task: a fee per message sent, per API call, per document processed. It sounds results based, but a task can be completed perfectly and still achieve nothing.

Why this is happening now

The honest answer is that software got better at finishing jobs.

When a tool only helped a person do the work, the vendor could not promise the outcome, because the outcome depended on the person. Now that software agents can run a whole workflow, from the first question to the final step, a vendor can put its fee on the end of that workflow. Fornelli by Design argues exactly this: once a system owns the full process, it can stand behind the metric attached to it.

The big platforms have started moving. According to ChatCenter, Intercom charges from USD 0.99 per outcome for its Fin agent, Zendesk prices per completed resolution, and HubSpot prices its customer agent per resolved conversation. ChatCenter also cites Sequoia Capital’s estimate that for every dollar companies spend on software, they spend roughly six on services, which is why vendors are interested in selling the work itself rather than the tool for doing it.

None of that means seat-based software is finished. It means buyers now have a better question to ask: what exactly am I paying for when this thing is switched on?

The case study: one conference, three results

Back to the operations head and her tablecloth.

Her company was running a two-day industry conference in Riyadh the following season, with sponsors in the foyer and a registration rush every morning. She wanted intelligent reception: kiosks that check delegates in by QR code, print badges, and answer the questions delegates ask a hundred times a day. Where is Hall B. What time is the panel. Is there a prayer room on this floor.

And she wanted to pay for what those kiosks achieved, not for their existence.

We were cautious, and we said so. A result is only fair when both sides agree what it is, when it can be counted the same way by both of them, and when the vendor actually controls whether it happens. If any of those three is missing, results pricing turns into an argument with an invoice attached.

So before we talked about hardware, we spent a full afternoon on a whiteboard trying to write down what a result was.

Result one: a delegate checked in and badged

The easy one still took an hour. Does a delegate who scans twice count twice? No. Does a VIP who is checked in by a protocol officer on a handheld count? Yes, if it goes through our system. Does a badge reprint count? No. We wrote each answer into the agreement in plain language.

Result two: a question answered without a handover

The reception host answers questions by voice or touch, in Arabic or English, and can hand a delegate over to a person when it should. We agreed that a question counts as answered when the delegate gets an answer and does not ask for a human. A handover is the system working properly, but it is not billed as a result either.

This is where the operations head pushed back. Surely a good handover deserves credit? We agreed, and suggested it go into the base fee instead. Paying per handover would reward the host for giving up early.

Result three: a sponsor lead, and the one we refused

Sponsors wanted leads. Here it got harder.

A delegate tapping “send me the brochure” on a sponsor screen is not a lead. A delegate who agrees, in their own language, to be contacted, who fits the sponsor’s target, and who has a real decision coming up, is much closer. We also added one human step: a named person from the sponsor’s team confirms the lead within two working days. If they do not respond in that time, the lead counts automatically, so a busy sales team cannot delay the invoice by ignoring it.

Then a sponsor asked for something bigger. Could we be paid a share of the deals that came from the conference?

We said no, and this was the most useful moment of the whole project. A deal that closes four months later depends on the sponsor’s sales team, their pricing, their product and a dozen other conversations. We would be taking credit for work we did not do, or losing money for mistakes we did not make. Fornelli by Design names this as the first problem with outcome pricing: when several things influence one sale, nobody can say cleanly who earned it. A result has to be something the vendor can actually deliver.

The floor, the cap and the base fee

The next question was money, and the answer was not “results only.”

Kiosks, printers, badge stock, content in two languages, a build that takes weeks, and a member of FAIM standing by every installation on site: those costs exist whether five hundred delegates arrive or fifty. A pure per-result fee would push all of that risk onto us. A pure flat fee would push it all back onto her. Neither is honest.

So the structure we sketched had three parts. A base fee for everything that has to exist before the doors open. An outcome fee for each of the three results, counted from the same log both teams can see. And a cap, agreed in advance, so the finance team knew the worst case before signing.

Fornelli by Design makes the same point from the vendor’s side: the vendor does the work up front and gets paid later, so contracts need floors, caps and clean data pipelines to stay fair. Done that way, the model stays fair to both sides.

Show day

The first morning was loud. Two buses arrived at once, the protocol team had a late change to the VIP list, and the foyer smelled of cardamom coffee and new carpet.

Check-in ran on the local network, so when the venue connection slowed down at nine, the queue did not notice. Badges came out with names in the right order in both scripts. The reception host answered the same three questions about Hall B again and again, and when an older delegate asked something it could not answer about a lost prescription, it handed him straight to a person at the desk. That was not billed, and it should not have been.

Around eleven, one sponsor found what looked like duplicate leads. It turned out the same delegate had visited twice and agreed to contact twice. The log showed it clearly: same badge, two timestamps, counted once. Nobody had to argue, because the rule had been written down months earlier.

On the second evening the operations head walked past the kiosk on her way out. There was no tablecloth. She took a photo of the screen anyway, for reasons she did not explain, and went home.

When the invoice went out, it looked less like a bill and more like a summary of the event: how many delegates were checked in and badged, how many questions were answered, how many sponsor leads were confirmed, each line tied to rows in an export her own team already had. Every number on it was one she could check.

This story is a composite drawn from common situations at conferences and exhibitions in Bahrain and Saudi Arabia, not a single client project.

Where Results as a Service goes wrong

It is not right for everything, and the people selling it should say so.

• Results outside the vendor’s control. Deals closed, revenue earned and brand awareness depend on far more than one system. Pay for steps the vendor really owns.
• Vague definitions. “Engagement” is not a result. “A consented, confirmed lead that fits these three rules” is.
• No shared data. If the client cannot see the same log the vendor bills from, trust breaks on the first invoice.
• Regulated work. Fornelli by Design notes that in healthcare and finance, outcome-based fees can look like prohibited revenue sharing. Take legal advice.
• The acronym itself. RaaS also stands for Robotics as a Service and, less happily, Ransomware as a Service. Write it out in full in contracts.

Where FAIM fits

We build the systems that produce countable results at events: reception and registration desks with QR check-in, badge printing and a bilingual host; interactive exhibition stands with lead capture that asks for consent; games and audience engagement with logged plays and leaderboards; wayfinding and smart event technology; and event applications that hand data over cleanly at close.

Our builds are offline-first, with redundant inputs and automatic recovery. Bilingual Arabic and English is standard. A member of FAIM commissions and stands by every installation, and we carry spares. In a results conversation, those details are what keep a result countable when the venue network has its usual bad morning.

Buyer checklist

• Can you write each result in one sentence that both sides would count the same way?
• Does the vendor actually control whether that result happens?
• Is there one shared log or export that the invoice is built from?
• What is in the base fee, and what rides on outcomes?
• Is there a cap you can take to your finance team before signing?
• How are duplicates, reprints and handovers treated?
• Is consent recorded, in the visitor’s language, before any lead is counted?
• What still works, and still counts, if the venue internet drops?

Related reading: lead capture architecture for exhibition stands, the conference registration queue that reached the revolving door and why event apps should work offline first.