HOME / COMMUNITY Switch to knowledge base

Email Customisation - Ability To Remove Embedded Links?

I’ve got this as a feature but I’d also say it strays slightly into being a bug too, in so much as it is a part of Quickfile that causes issues.

I have always used my own SMTP service for Quickfile but still get plagued with issues on deliverability because of spam filtering on destination servers. I also get the odd Quickfile invoice sent to me which sometimes ends up in my spam folder. I believe the main issue is down to the content of the email, which contains a few maybe not entirely code compliant sections and the embedded links that some filters pick up on. This could be mitigated if there could either be more options for customising the underlying template, e.g. allow the links to just be plain old links not embedded HTML links, or an option for entirely plain text emails.

Any movement or planning on doing anything with email at all?

It’s actually starting to cost me money now as just about every invoice I send out ends up in someones junk folder. I either need to send the invoices manually (defeating the point of the recurring invoices) or … well that’s it really. I can’t do anything else.

I don’t want or need any HTML at all in my emails. None of the things in the email directly make it spam, but all these things get a few marks to the point where the Quickfile emails just trip the spam threshold. It’s not Quickfile at fault here, it’s the whole email/spam system as a whole. I am losing money, I am also finding customers sending me invoices from Quickfile are ending up with their emails being filtered into spam, which sometimes means I don’t even get to see them after the event as spam gets deleted.

Just give me the option to send out emails with no formatting or embedded stuff.

Hi @Lurch

This is on our teams list and will be added shortly. We’ll keep you posted :slightly_smiling_face:

1 Like

Hi @Lurch

Just a quick one to let you know that this is now available.

Instead of using @DirectInvoiceLink@, you can use @DirectInvoiceURL@ which will output only the URL of the link, with no additional HTML.

1 Like

I used it today on an invoice to a client who auto-acknowledges all incoming (non spam) emails. No acknowledgement and a cc to myself ended up in my spam folder.

Looks like the anti-spam algorithm writers are ahead of us again.

I might try out an interesting service from Royal Mail where they will actually take a hardcopy to the client’s premises for just 70p!

1 Like

I’ll update the templates and review how this works out. I’ll report back soon!

2 Likes

OK, I see how this works now. It just gets sent out as formatted text, which isn’t really what I was hoping for. This means the client has to copy and paste the URL into a browser? It appears plain text links encoded with base64 don’t get parsed. I was hoping to just lose all formatting/encoding entirely and sent a text/plain email with the text of the email template as the body. Nothing more, nothing less!

There’s also this error that pops up when I manually send an invoice. No sure I’m ready to change templates just yet…

Thanks for screenshot @Lurch - I’ve logged that to be updated.

Apologies for misunderstanding what you were after - possibly me being on a different wavelength there! Do you have an example of the sort of thing you were looking for?

1 Like

It should output the raw URL, although the benefit of having this token is that you can embed it into your own custom link as follows:

<a href="@DirectInvoiceURL@">Custom Link</a>

Unfortunately there’s no way to set the email to plain text, the platform we use for sending mail only allows for multi-part emails.

1 Like

Ah, I see. I’ll have to have a play with this then and see what I can do as I think the main issue is the multi-part/html email.

Can you use the same token multiple times in the same email?

Yes you can use the same token multiple times.

Our emails score reasonably well on mail testing tools (see example I just created here). Since February we’ve also created custom sender addresses for every account, rather than binding the reply-to field with a different address (which has become increasingly problematic), we then proxy the replies.

The UUID approach could work, although we’d need to look at the complexity of this vs how widely it would be used. If anyone wants to open a new feature thread for this we’ll certainly look into it.

They are better than they used to be but I still get clients with my invoices in junk, as recently as the last week or so. I’d still just like an option for text only, I don’t need to send any HTML at all for any reason.

It’s almost impossible to nail down all those cases, each receiving mail server has a proprietory set of rules for rejecting mail and we can never know what criteria they use, as this is not publicised. The only way to get some assurance is to ask customers to add you to their safe sender list.

I’m not convinced sending plain text only emails will make any difference? Currently we send HTML and plain text variants together inline with recommendations. Also do we really want to go back to plain text emails and telling people to copy, paste long links into the address bar in their browser?

Somewhat defeats the object of using QuickFile if I have to contact customers before sending them an email. I might as well just send them the link to the invoice.

It’s sent as plain text but most clients (mobile, PC, web…) will happily parse the text and create a link. I always send plain text emails and 99% of the time they arrive as links on users machines. That’s all I want it to do.

It’s not a problem unique to QuickFile. Any service that allows for the sending of email on behalf of a 3rd party can end up in junk. More so given that we allow users to customise their email body. If there’s a certain trigger word or composition of words in an email, some mail servers can deem that as spam. The fundamentals of how we send emails is about as good as it can be, email is not a perfect means of communication.

Regarding plain text only emails, if you post that to a seperate feature thread we’ll consider the options.

True, I wasn’t meaning to say it is specifically a Quickfile problem, I know people using other software have same issue.

If you’re sending using my SMTP credentials though you’re sending as me from my servers? I send from many devices using several aliases so you’re not doing anything different to me, but my emails don’t end up in junk.

It’s within this thread, which I suppose I should re-title and re-purpopse as there is some relevance in the comments. Could move this chat to there too I guess.

OK I’ve moved this discussion into the email customisation thread.

Regarding SMTP, that would need to be investigated. In theory yes the email success rate should not differ between QuickFile and other client tools. Although the body of text being sent can be a factor. Fake invoices have been the target of scams in the past, so some wording you’d specifically use in QuickFile may increase the risk of being flagged.

You could try setup a dummy client with an email generated on https://www.mail-tester.com/ and check the score. The test that I did earlier used our own internal email send routine (built on AWS). You may get a different result if you have your own SMTP configured on QuickFile, would be a useful test to highlight any potential issues.

Like you say, email is not really a great tool for reliable communication these days. Another ‘great when it works’ thing! I’ll have a go with the tools later and see what I can tweak, if anything. Last time I checked though there wasn’t really anything that I could improve, biggest issue was HTML body and general format/headers. I might have to just relent and set up my own server to intercept these messages so I can forward them on myself.

1 Like