A Guide to Tipping in the Gig Economy

The Gig Economy is a term made popular for freelance or contract workers who take freelance jobs on-demand. These freelance jobs have become known as “Gigs”, hence the term: Gig Economy. 

If you are a company, then paying for just what you need, just when you need it makes perfect sense. To a lesser degree, it also makes sense for the workers, but only really if your circumstances necessitate your need to be flexible and you don’t, on the whole, object to low pay!

I recognise that some freelance work pays highly, Consultants and IT Contractors for example, but many are delivering pizza or driving taxis. Many Gig Economy workers rely on tips to supplement their freelance income, as do many service workers like those waiting at table.

Tipping is an accepted and end-of-service activity in the US in almost all service interactions. This is not so much the case in the UK. Here in the UK, we have a certain difficulty with the concept of tipping. Often we can’t work out if a tip is expected … or if offering a tip might cause embarrassment. If offering a tip is acceptable, we don’t really know how much of a tip to tip, and if we tip too little, well that might be embarrassing!

It isn’t because we are inherently mean, although some of us are from Yorkshire, it’s because it’s not something built into our national psyche. However, that might change with the Gig Economy and the erosion of the real value of the minimum wage.

New and developing technologies have changed the relationship that many of us have with work, and you can bet that if it hasn’t already changed the relationship, that change is on the horizon.

For those of you expecting an article about the Gig Economy, this isn’t an article about the Gig Economy. This article is about Tipping in the Gig Economy … about developing electronic tipping systems and services that are likely to be driven by the working relationships underpinning the Gig Economy.

How does the Gig Economy work?

The Gig Economy allows for work to be broken down into bite-size chunks. The bite-sized chunks are then “sold” individually to the “giggers” who complete the task and are paid accordingly.

Bite-sized chunks of work – a pizza to be delivered, for example – are received from the client at the time the service is required. The bite-sized chunk is received and is held in a queue by some administrative central system until a “gigger” is available to complete the task and fulfil the requirement. The skill and therefore the added value delivered by the service provider is in its ability to provide a “gigger” at precisely the time that a “gigger” is required!

Not surprisingly, mobile apps support the Gig Economy. In fact, it’s likely that the Gig Economy could not have developed as it has done without the availability of the technology. Mobile phones and mobile data have delivered what is essentially a virtual workplace. Workers can use their apps to register their availability for work, the apps can receive the instructions and the same apps can monitor the progress.

Tipping in the Gig Economy

Tipping the person delivering your pizza is becoming more of a thing, even in the UK … and Yorkshire. But, if tipping is going to be the new norm, it should exist in its own right and not as a function of the gig operator.

Tipping is a financial transaction that takes place between the receiver of a given service and the deliverer of the service that represents the quality of the interaction between the two parties. The size of the tip is not related to the quality of the pizza!

In the old days, tips were usually offered, and accepted, as cash. Cash has its advantages insofar as it’s invisible to employers and to the taxman, although the taxman will usually have no problem taking a guess at the amount and then expecting the tipee to prove otherwise.

It is not unheard of for employers to take cuts from tips, to make adjustments to wages based on tip amounts and to share tips across teams. Some of these actions might be fair, but some aren’t!

There are only a couple of ways that a tip can be paid and received in the Gig Economy, which to be fair is pretty much the case elsewhere too. Without going into too much detail, it might be through a separate payment administered via the virtual workplace mobile app or it might be via a cash transaction. The virtual workplace app is convenient but is open to abuse and it leaves a trail; cash is simple to understand, straightforward to operate but in short supply as a result of the pandemic.

What is needed is a tipping mechanism that is independent of the gig service being provided and which does not depend on cash.

Tipping the Pizza Delivery Boy Electronically

First of all, we know it’s going to involve technology.

We can’t rely on cash because no one has any anymore. The ATMs stand-alone and cold outside on the High Street and they stand slightly warmer inside Convenience Stores, but they are not being used. Contactless payments look set to be increased to £100 (which I do not consider to be an issue) and I have the same £20 note in my pocket that I put in my pocket last March!

So, let’s phrase the requirement, scope the proposition and set the user expectations.

Requirements for Electronic Tipping

Throughout the following, I am going to be using the term “cash” to represent the concept of value rather than the folding and the jangling. I think we can all agree that “Flash the Cash” is so much more down with the kids than “Initiate a deposit into my online bank account”.

As always, I shall be keeping stuff simple and will avoid the use of technical terms wherever possible.

So … the requriements for an lectronic Tipping application are broadly:

• no folding money or jangling cash
• no apps to download
• the financial transaction is between the service receiver (Tipper) and the service giver (Tipee)
• neither party should become aware of the payment or banking details of the other party
• the cash value can be any amount (ie not pre-set)
• payments should be made and received in real-time … wherever possible

But that’s not all … not surprisingly, there are tax implications associated with receiving tips. In the UK, if tips are received in conjunction with work, whilst they do not count towards the National Minimum Wage, they are taxable. I am aware of similar rules existing outside the UK as I have had to design systems to take account of this.

• retain records of tips for tax purposes

There are also government (UK) guidelines for employers that handle tips on behalf of their staff, which might be pertinent and worthy of consideration if any tipping information is passed across employer systems. Something to keep in mind as we may need to refer back and consider this later.

Let’s discuss the process of tipping …

We are not going to be using the foldy or the jangly kind of cash. This means that assuming we are not thinking about implementing some form of Talley System that records tip liabilities using notches in sticks, the value transfers are going to be electronic.

Before we begin, we can be pretty sure that we cannot initate a payment from one account to another without being logged into the sending account. It is not possible, for example, to send ad-hoc instructions to a third-party account telling it to make a payment to a second, third-party account.

Think about it.

If I want to send a tip but I don’t want to be sharing Account Numbers and Sort Codes, then a “middle-man” is required.

So … options for a tipper funding the tipping process would be:

• credit card
• debit card
• pre-funded non-bank account
• current account

… and options for recieving the tips would be:

• current account
• tipping-service provided account
• pre-paid card

These lists are not meant to be exclusive; there may be alternatives depending on location and situation. Ultimately, the prevailing options will depend on the overall proposition.

A card-based solution is probably the easiest to consider. There would probably be a cost differential between credit and debit cards but shopping around and negotiation might reduce the impact. If you are going to be considering a pre-funded non-bank account (pre-paid card!), you should also consider the potential complications that could easily surface, around top-ups for example.

Current Account funding is possible, and three mechanisms spring to mind: cash push from the account, direct debit from the account and Open Banking. I am aware that (1) and (3) are potentially interchangeable in principle, but they are not interchangeable in a practical sense. Direct cash push would require the account holder to be logged in whereas the Open Banking option doesn’t.

Sending cash, real-time, from a current account generally requires the account holder to be logged into the account and in a position to initiate the required transaction. Here, the instruction would be to send the cash to a specific account, which would mean the tipper knowing the Sort Code and Account Number of the receiving account, and this goes against our initial requirements.

An alternative approach might be possible using Paym as it is driven by mobile numbers rather than bank account numbers, but I don’t think of this as a serious consideration.

The Direct Debit option may be the cheapest but it’s also the least appropriate for this application. Direct Debits in the UK can be recalled at any time and in any case, the value would not be transferred in real-time … unless your idea of real-time is around two to three days. Of course, this may be different elsewhere.

A suitably aligned Open Banking solution may well be in a position to come to the rescue, securely transferring value in real-time … but it’s quite a complex process to implement.

And then there are the options for receiving the tip.

As a tip receiver, I would have nothing to pay the bank for receiving the funds into my current account. The tips would be received in real-time from the sending bank and the sending bank would pick up the tab for sending, whatever that might be. I remember from my time in Corporate Banking that Corporate Banks charge for everything, so the cost of a Faster Payment from one UK bank account to another may include a not-insignificant cost to the sender, which would need to be factored into the proposition business case.

An alternative, although one that I don’t particularly favour, would be for the tip service provider to retain all tips until they are requested by the tip receiver, hopefully as an accumulated amount. The cash transfer could be generated on an ad-hoc basis or perhaps when the accumulated tips reached a pre-arranged amount.

A pre-paid card issued to the tip receiver could also be a more cost-effective option than cash transfers into a current account. In this scenario, tips would accumulate in a card account administered by the tip service facilitator, which may reduce cash transfer costs as all tips are essentially held in the same value-bucket. Tips received from happy customers would be allocated to the appropriate card account, which would be an accounting function rather than a value transfer function. This may be worth considering but the conclusion isn’t given. The cost of cash transfers would need to be weighed against anticipated transaction volumes as there is a cost associated with card issuing.

My preference would be for the tip to be paid using a debit card (or a credit card at a pinch) and then the accumulated tip value deposited into the appropriate current account on a daily basis. I see no value in making a transfer for each individual tip as each tip transaction is subject to some flat rate charges. It would make sense to accumulate the transfers and pay for just one – this would also mean that service charges can be kept low.

Transferring Tips from Tipper to Tipee

I am going with my preference as it seems to me to be the most sensible choice.

So just to recap …

The Tipper is overjoyed, appreciates the service provided by the Tipee and wants to show that appreciation with a Tip … but the Tipper has no jangly cash. Apparently, this is a situation that is becoming increasingly common and I can understand why: there is no need to carry cash anymore and I have been hanging on to the same £20 note since last March!

We need some way of accepting the tip from the Tipper, and we have gone with a Debit Card. It’s not the only option but it’s fairly straightforward and reasonably well understood. The act of taking cash from a Tipper isn’t complicated, the complications are hidden behind the Tipee … we need to ensure that there is enough information to identify the recipient Tipee so we can deliver the tip.

And this is where the fun starts …

The Tipper wants to pay some cash to the Tipee but does not know any of the information that would be required to do so, and we have also established that Tipee details should not be made available to the mobile phone.

We essentially need to associate the Tipee details (name, account number and so on) with a payment amount generated by the Tipper, but we cannot do this on the Tipper’s mobile phone.

The following implications need to be acknowledged:

• A QR code is the easiest way to transfer complex information from paper (or LCD screen) into a mobile phone. In most cases, QR codes are recognised and acted upon immediately by the device if the camera is activated.
• Given the requirements, the QR code cannot carry the Tipee’s account details.
• Given the requirements, the tipping service will not be facilitated by a mobile app, although many are so this configuration should not be discounted.
• Given the circumstances, the QR code cannot initiate a bank value transfer on the mobile phone, even if the account information were available.

QR Codes on Restaurant Receipts

At this stage in the analysis process, it’s worth pointing out that the QR code route could well be flawed, for two reasons.

Any organisation considering using a QR code as a means of initiating a process, any pocess, must bear in mind that they are not going to be the only organisation considering the use of QR codes as a means of initiating processes … a point that is often overlooked by the zealous entrpreneurs looking only in one direction.

The payment industry is to all intents and purposes a collaborative enterprise; it has to be collaborative or it simply would not work.

Unless you are one of the Big Boys:

Clover, part of First Data, which is now part of fiserve, which makes them pretty much a global player, has recently introduced the bottom-of-the-receipt QR code that allows customers to pay their bill using Apple Pay.

You can learn more about the Clover “dine ‘n’ dash” proposition in 9to5mac but the fact that it is now possible to integrate Apple Pay (and I can imagine that Google Pay isn’t far behind) with a real-world checkout process means that it’s probably here to stay.

Imagine the bottom of a restaurant receipt that had to contend with multiple QR codes.

It’s not a completely unworkable situation, but it’s not pleasant … and if there is a battle for the QR real estate waiting at the bottom of the receipt, the global players are not going to lose. In my opinion, the main reason they are not going to lose is that it’s actually not a bad idea, and it is also likely to gain traction with the paying public. As I have said, I am not a fan of QR codes but I am pragmatic, and the people in the Far East love them!

I am going to continue with the analysis based on the use of the QR code. In the short term, the QR code is an acceptable and working option and in the longer term, even if the use of the QR code needs to be reconsidered, the logic that underpins the information flow will remain the same.

A Central Tipping Point

I am sorely tempted to use the logo from the TV program of the same name, but I am aware of the negative gravitas score that would inflict. I also can’t find an image that I could use without fear of a slap.

It doesn’t take much of a leap of faith to recognise that there must be a Central Tipping Point where the magic happens.

The Central Tipping Point must, as a minimum, fulfil the following functional requirements:

• maintain records of Tipees, Tipee bank accounts and Tipee payment histories
• support a Tipee website allowing Tipees access to this information
• support a Tipper website allowing the Tipper to …
  • see who they are tipping
  • see what they are tipping for
  • select an amount for the tip
  • select a payment option for the tip
  • a history of their tipping activity
• support multiple payment options for the Tipper
• support multiple receiving options for the Tipee

This article is not about the development of a working Central Tipping Point, it’s about the information necessary to make the Central Tipping Point work, how it moves around and how that might be facilitated using a QR code.

The first thing that we are going to need is a relationship manager that can manage and maintain the Tipee relationship and Personal Details (including Payment Details). There is also a case for managing and then developing the relationship with the Tipper, but the extent of this requirement will be determined by the potential services that might be offered to the Tipper.

The Central Tipping Point and specifically the Relationship Manager serve to decouple the Tipee information from that of the Tipper … necessary to maintain the initial “Flash the Cash” premise.

Tips from the Tipper

The Tipper has received the service, whatever that service might be and wants to tip. The information necessary for initiating a tip can only come from one of two places, either the fulfilment agent (the Tipee) or the fulfilment service (for whom the fulfilment agent is working).

Let’s look at the first scenario: the Tipee presents the Tipper with a QR code on paper, on a card or maybe on the screen of a mobile phone. Here, the QR code contains the URL of the Central Tipping Point and a Tipee reference code. This allows the Tipper to connect with the Central Tipping Point in favour of the Tipee. In this scenario, there can be no direct reference back to the organisation the Tipee is representing, but it is possible to make references indirectly using geolocation. At this point, it’s worth mentioning TipFlip as an alternative model built on mobile apps and geolocation – but this is outside the original scope so we will discount it for now as a potential value-add for later.

Here, the Tipee has registered with the Central Tipping Point and has been provided with a QR code (1). The Tipee shares this with the Tipper by whatever mechanism is appropriate. The means by which the QR code is shared with the Tipper is not important as it doesn’t affect the logical data flow (2). What is important is that the Tipper receives the information and can use it to connect with the Central Tipping Point along with a reference that identifies the Tipee.

Now, we have established a connection between the Tipper and the Central Tipping Point, and we know the Tipee reference number. Once we have established an amount for the tip, which may be a pre-defined amount to click on or it may be a free-form field, taking the payment from the Tipper is straightforward … well as straightforward as anything in the payment world can be. Applying the cash to the Tipee’s account is also logically straightforward once the payment frequency policies have been agreed upon.

That was easy, but what we would really like is for the QR code to appear on the receipt from the Pizza Shop.

It is likely that the Pizza Shop is going to need to be registered with the Central Tipping Point, especially if the QR code is going to include a reference back to the Pizza Shop, which isn’t an unreasonable assumption if the Pizza Shop is going to benefit.

At this point, we should be asking two questions:

Question 1

What’s actually in it for the Pizza Shop. We know this service has the potential to assist the Tipee, and we will be charging for that assistance … but are we asking too much of the Pizza Shop if we’re asking them to help solve a problem that they haven’t really got? And they would need to liaise with their own suppliers too … some things to consider before applying developers to the task.

Question 2

The Gig Economy is built upon an alternative relationship between “employer” and “employee”. Given that, I would be asking how appropriate it would be to build a tipping platform that defined the Tipee in terms of the Gig Employer. I am making no judgement but the question needs to be considered.

Also, I’m not even sure that those terms hold any meaning anymore, and now that the UK Supreme Court has confirmed that Uber Drivers are indeed employees, let’s not make too many assumptions too soon.

Back to the now:

Somehow, the QR code will be stored somewhere within the Pizza Shop domain, ready for inclusion on the receipt. I would expect there to be a reference code that links the future potential tipping transaction back to the Pizza Shop.

At this point, I feel a discrepancy between QR code data and QR codes. I would begin asking questions here about the generation of the QR code: is it going to be generated by the Central Tipping Point and then delivered to the receipt printer as an image, or is there some code in the receipt printer that can turn the data into the required QR code? This isn’t a simple question if the QR code is to include images like those above. Something else to think about.

We still need a relationship with the Tipee, obviously, and now we also need a relationship with the Pizza Shop … and because we are delving into the POS and the receipt printer, we are going to need relationships with terminal suppliers and POS manufacturers and EFTPOS system integrators and possibly acquirers … and each relationship is going to be different, and we need to get to the point where a one-size API framework will fit all.

The Consequence of Analysis in Product Development

If we didn’t do analysis, everything would be simple.

If we didn’t listen to analysts, everything would be simple.

If we just ignored analysts, everything would be simple.

We live in a complex world, nothing is simple.

I have tried to write this article sequentially, to reflect my thought processes. I have following a process and I have added thoughts as they came to me and added questions as they arose. When I began, I thought it was going to take me about a day, and it’s taken nearly two … so there is surely a lesson there – and I have been doing this a long time.

I have concentrated specifically on the high-level data flows and the consequences of relationships between parties. Even at this high level, I know that I could have followed many rabbits down many holes and written many more pages. The trick is to know which rabbit to follow, and that depends …

I can see that there are loads of questions hiding just below the surface.

The Consequence of Analysis in Product Development is that it surfaces questions that need to be asked of people who do not want to be questioned.

---