A few weeks ago I settled on the first version of my idea to help freelancers in the event of late or non-payment. It looks like this:

• interactive walkthrough
• personalised action plan
• practical assets like templates and tools

This should be enough to address a pattern that cropped up during discovery calls—that freelancers aren't aware of their rights when it comes to non-payment.

Although the first version appears simple, I felt overwhelmed when it came to planning. According to our claims data, there are 4 common drivers behind payment disputes. These are:

1. Non-payment due to dissatisfaction with the work
2. Non-payment due to cashflow issues
3. Refund requests
4. Non-payment due to liquidation

To make things trickier, some clients mask cashflow issues behind a complaint or criticism with the work. Other clients never offer a reason. They ghost the freelancer, making it challenging to understand the motivation behind non-payment and what action to take.

There's another layer of complexity. It became apparent from our discovery calls that the relationship freelancers have with their client dictates how they want to handle payment disputes. If the relationship's been positive up until that point, it's unlikely the freelancer wants to involve heavy handed tactics.

(What do I mean by heavy handed tactics? Anything with a legal element. Small claims court, letter before action, insurance.)

All of this to say, whilst a client might not pay due to cashflow issues, there are different ways to approach this depending on:

• the relationship between the freelancer and client
• the invoice amount. There's a sliding scale where the value of the invoice determines what action the freelancer is comfortable taking. Again, this was highlighted during discovery calls
• what methods have been exhausted already. If you've followed the formal late payment process, you're not going to need us to guide you through it

This is why it felt overwhelming! There are many outcomes. There are countless variables. My head hurts when I think about it.

When I mentioned this during my 1-1 mentorship session, I was given a great piece of advice. Check our existing claims data to gauge what the most common reason for non-payment is. The first version should be designed around solving that.

Whilst it makes perfect sense, for absolutely no reason I've decided to ignore that advice and address the 4 common drivers behind non-payment.

Years ago I worked with Scott Riley, a designer who is responsible for With Jack's marketing site and quote system. I remembered Scott used a tool when storyboarding different moments for With Jack customers.

It's called Miro. This is what I used to map out the non-payment flow, including various outcomes depending on the answers provided in the interactive walkthrough.

Now that the flow is mapped out, it's going to make building the first version a lot easier. Techscaler encourages non-code tools, but I have a degree of technical knowledge (and I've already validated with a manual test) so I'm going to dive into the build.

P.S. I've applied to pitch my idea at the Techscaler showcase next month. I've been finding it hard to make progress since learning of my mum's health. Hopefully my pitch is accepted because I think this would give me some much needed accountability with the build.