Test your client-facing tech (instead of assuming it works)
Technology is great and can be an absolute gamechanger,… until it isn’t. Then, there’s all sorts of frustrating little hiccups, glitches, and weird UI bugs where the software that you bought to make your life easier, now makes your life much much harder. And, when that software is really acting up, you can ping support thru that annoying little chat bubble, dig up knowledge base articles, or Google for solutions. But, when your client uses your software (eg, client portals, project management you’ve invited them into, invoices, etc) and something goes wrong, they don’t have the same options. They can’t contact support. Most client-facing software obscures who built it (even if it isn’t fully white-labeled), there’s very rarely support for guest accounts, and even if they got through, they don’t have admin access. The best they can do is refresh the webpage and clear their browser cache.
And, those sorts of tech problems can create a lot of friction, a poor client experience, and in some cases, cost you money. You should get ahead of all those issues by regularly going thru your processes as a client would. And, that’s not just mapping their journey (like, ‘oh, first they visit my webpage, then schedule on Calendly, then get an email’ etc), but actually interacting with the tech and seeing what happens. Create all the accounts, click all the buttons, and run thru the software like a client would (especially one who isn’t already aware of how it works) so you can preemptively find and fix any problems.
Create a designated dummy email :
You typically can’t add the main admin email as a guest to the same software (in other words, if you set up your project management software with your main email, you can’t also add a guest with that email and, if you coulddd, there’d probably be unintended issues). You’re gonna need a secondary email account to test all your systems and software. There’s a few options:
- Aliases: Some email service providers let you create email aliases on the fly by adding a + and an identifier right before the @. For example, you could add “+calendly” right before the @ in your email address and it instantly becomes a separate alias that you can test Calendly with. The downside is that, because it’s just an alias, all the email notifications you send that email will land in your normal inbox and it could get cluttered.
- Temporary emails: Temporary emails are typically used when you want to download a lead magnet (eg, free ebook, checklist, etc) without getting spammed. There’s dozens of temporary email services (just Google ‘temporary email’ or ‘burner email’). The downside is that they’re, well, temporary and won’t exist long enough for you to check the follow-up emails and reminders you send clients (and, some software can detect and block temporary emails, making your testing process much more complicated).
- Secondary emails: You could also create a totally separate secondary email for testing (and downloading those lead magnets that’re totally gonna spam you) via a free Gmail account. This is what I do. The downside is that you’ll have to remember the password and log into it, but there’s so many password managers and you can quickly swap between Gmail accounts so that’s just a minor nuisance.
Send yourself invoices, portal invites, esigns, and requests:
Friction slows down how quickly clients will pay your invoices, accept your portal invites, and respond to requests. You should specifically test these client bottlenecks for friction, ambiguous instructions, and unintended options. For example, send yourself a dummy invoice for $5 and try to pay it. Make sure the payments process is obvious, easy, working as intended, and that the invoice is complete and correct. And, if you only accept ACH/bank debit, make sure the credit card payment feature is truly turned off. On a $5,000 invoice the fee difference between credit cards and ACH is roughly $150. Testing and correcting that issue can save serious money.
(How do you like that for a finance tie-in? 😉)
Trigger your automations :
Automations are wonderful. They take so much admin work and data entry off our plates. But, over time, our automation stacks become bloated and, sometimes, they break. While testing your software, try triggering all those automations and Zaps to see what happens. Make sure they fire like they’re supposed to. And, make sure that overlapping automations don’t bombard your clients with notifications (for example, make sure you can’t accidentally sign up for three different intro email sequences).
Reduce friction and unintended results:
Once you’ve found the friction in your client process, you need to remove it and make things easier for your client to understand. That could be as simple as tweaking some features in your software or including a brief templated explanation (for example, help docs, walk thru videos, and screenshots). Or, as complex as changing software and reinventing processes (for example, switching from sending e-payable invoices to auto-debiting bank accounts).
How frequently you should review:
You should test your client-facing software at least once per year. If your tech stack stayed the same, just run thru it quickly to double check it’s working as intended. If you run a larger business with a lot of employees, client onboarding, and moving parts, you might want to test it more frequently (like once a quarter or every six months). And, you should definitely check it whenever you onboard a new software tool or change your automations/Zaps.
Send yourself a $5 invoice.
🚀 Strategic Accounting 🚀 - In-the-trenches strategic and financial business advice and serious, candid conversations for small digital agencies (incl freelancers) for when you have the client work under control but need help with the business glue that holds it all together.
🏛️ Tax Compliance 🏛️ - Taxes, accounting, and payroll to keep your business on the IRS's good side