Hacker News new | past | comments | ask | show | jobs | submit login
Dear SaaS vendors (liip.ch)
160 points by market_arts on Jan 18, 2018 | hide | past | favorite | 90 comments



As an European, my biggest wish for most SaaS vendors is an alternative to credit cards payments. SEPA Direct Debit or normal bank transfer after the invoice would be a godsend.

Credit cards are much more uncommon in Europe (people use debit cards, business get invoices paid through direct debit), and using credit cards for ongoing operational expenses is unheard of. This has caused a lot of friction with the accounting department of the companies I've tried to introduce some SaaS.

Usually, the solution is that one specific member of staff gets a personal corporate credit card and has to do tedious declarations and administration.


As a SaaS vendor with customers in the EU, bank transfers have been a huge pain for us. We have to log into the bank website to confirm we’ve received an amount. Then we have to match it up with an invoice, mark it as paid, etc.

Conversely, with a debit/credit card that’s all automated. No manual labor involved.

Could we automate international bank transfers? Probably. But customers end up using a debit/credit card because it’s the only option offered.

We recently rolled out ACH bank transfer payments (US only) and offered an amazon gift card for anyone who wanted to switch. <5% of our customer base utilized this option.


You may want to look into the SEPA direct debit system. It lets you send a file to your bank to request transfers and they send you back a file with the results.

You have to register for a debitor identifier and ask your customers for permission to debit their accounts first but overall it works well and can be automated. It's the standard way to do direct debits in Europe.


Direct debit doesn't work with all companies, it certainly would not work with ours. It gives too much control to outside parties.


Within SEPA direct debit, you can reverse a charge if it was unwarranted.

In my experience, it's a lot more common and accepted than credit card business payments in Europe.


European accounting and/or invoicing software can automatically read in your bank statements, detect paid invoices and mark them as paid, no manual work!


Choose a bank with API. My bank has it and it is easy to automate this process.


Any recommendations?


Czech Fio banka is the one I use, http://fio.cz Allows you to create read only or full access tokens.


The world is small... I always liked Fio, they had documented API and you could do whatever you wanted even in ages, when other banks insisted on using their software.


After PSD 2 directive comes into effect (expected 2019?) all European banks will have to have an API.


Actually we’ve been prepping for 2018 launch.


Who is we? :)


Soon or later all banks in Europe because of psd2.

You might also want to check out figo and fidor.


GoCardless (YC S11) allow you to accept direct debit payments across Europe:

https://gocardless.com/


This is not available for businesses based in the USA[1]. Also, the maximum amount for a single transaction is €5,000, which is inadequate for many (most?) B2B SaaS products.

[1] https://gocardless.com/faq/merchants/international-payments/

[2] https://gocardless.com/faq/merchants/

edit: link #2


Even in the US, I can't pay a $5000 invoice on a credit card. That's over the threshold where either they accept a purchase order, or we can't use them at all.


> have been a huge pain for us

Opportunity, business idea seekers!


This! In a world where very startup tries to deal with "sexy" problems like ML, AI, blockchain / distributed ledger, ... there is a lot that can be done to just ease the problems real enterprises have. This is for sure one of them - payment processor which takes CC and SEPA, with proper API and automations.


Stripe offers SEPA


well blockchains are about payments


Stripe offers SEPA in Europe, but I believe it’s still in Beta. We integrated it, but after having some trouble with the equivalent of chargebacks, we measured customer adoption compared to credit cards and PayPal in Europe and didn’t see a big shift. We pulled it out. We’re a B2C though so it could work for B2B more reliably I imagine.


after having some trouble with the equivalent of chargebacks

Would you share more details about this, if you can?


not sure if it fits easily into a HN comment, so feel free to drop me an email. Things might have changed or improved since.

Generally, it's way too easy to reverse a SEPA payment for a customer (up to 8 weeks if I recall after purchase). It led to some, admittedly rare, cases where we can issue a refund to a customer and then they'll reverse the payment as well. So we ended up with negative revenue to the same amount of what we charged, which can be up to 190 EUR. So we'd actually refund 190 EUR and then lose another 190 EUR + Stripe chargeback fees on top. Ouch. There was little or nothing we could do about it apart from begging the customer to transfer the money back to us...

On top of that, there were chargeback fees even if the bank, rather than the customer, reversed the charge. This happens not too infrequently (IIRC around 5% of transactions). If this was a credit card transaction, the bank would simply decline the charge. With SEPA it's not as simple... The charge gets through, supposedly, and then bounces with a chargeback fee...


Thanks for the insights. Ironically, we've been looking at accepting SEPA for European customers primarily because card payments haven't been great for us in terms of reliability. We've never had a problem with UK customers paying by their version of Direct Debit, where there is also an automatic right to reverse a payment, and certainly not with banks reversing charges without customer intervention, so it's good to know this is something we'd need to watch out for with SEPA.


As far as I know, Stripe SEPA is only available in EUR currency[0], so this nearly excludes the UK completely. At least for us, all SEPA payments were outside the UK. Probably 95% from Germany and Austria, and the rest from a few other EU countries. Not a huge sample size, but we've been running with SEPA for a few months. We did an A/B test for a a few weeks as well, and basically observed no hit in total revenue when we offered SEPA or without it (only cards and PayPal), so that was the main reason we pulled out the plug. Not just the chargebacks.

Another thing I should mention is the async nature of the whole thing. Unlike cards that get authorized/declined instantly, we're talking days or weeks with SEPA. For a monthly subscription, this eats into the first month easily.

Again, we're talking about private individuals here (B2C), typically students in our cases, and as I mentioned predominately from Germany, so YMMV a lot with other customer types or countries.

[0] https://stripe.com/docs/sources/sepa-debit#create-source


Thanks again. These are all interesting data points. There are certainly a lot of similarities between what you're describing and what we were envisaging setting up. The lack of increased revenue when SEPA was available is particularly worrying, as we know in our case that from time to time we get requests from customers who don't use credit cards, and we were hoping SEPA might be a more accessible alternative for that part of our market.


feel free to drop me an email and I'd be happy to answer any questions if you have (see my profile)


I'd also be interested to know more about this - I would have thought such behaviour would be comparatively rare for B2C.


Gah, sorry, just ignore me, I mixed up B2B and B2C!


I think it depends on the country. Here in Denmark, everybody has a credit card – actually a "Visa/Dankort" – where our own type of card (Dankort) is combined with a regular Visa CC. However, those under 18 either have a Visa Electron or MasterCard, which are debit.


I was mostly talking about business customers though. Do all businesses have company credit cards for operational expenses in Denmark?

Interesting that people in Denmark use a credit card, although Wikipedia seems to imply it implies as a debit card inside Denmark? [1] I know debit is definitly more common in the Netherlands, Belgium and Germany.

[1] https://en.wikipedia.org/wiki/Dankort


I rarely had problems with customers using a credit card. Had to be sub $10k/month otherwise we did an invoice. Invoice weren't difficult, just required a little more effort.


I'm surprised not to see my biggest gripe with most services mentioned - half-baked account systems, without proper role or group-based access control.

Every startup I've worked at has had some variation of a shared 1Password account, because most Saas services require a single root account (and I've never heard of a best practice for managing 2FA on any of these root accounts).

The worst ones of these Saas companies don't even support multiple accounts at all, so anybody on the team that needs to log in always uses this shared account (which is a complete nightmare when anyone leaves the company, as well as far from ideal from a security perspective). The better ones also support separate accounts and roles or groups that you can assign people to for granting permissions. At least then nobody needs the root account for day to day use, so not everyone needs access to it meaning if anyone leaves you can revoke revoke their account without rotating the root password. But even a lot of these still require some sort of "owner" or root account to be hanging around somewhere, which doesn't belong to a single person.

It's very rare in my experience to find a Saas company that uses exclusively role-based access, where "owner" or whatever the top-level permission is is just another role that can be granted to anybody's individual account.


Shared accounts are an operational and security nightmare. If everyone shares the same credentials its impossible to cut off a former or disgruntled employee without disrupting everyone else's workflow. Its no wonder that SSO solutions like Okta are taking off


As an indie SaaS developer, I know I need to add group-based access control and I was looking for an off the shelf solution but I was surprised how complicated this is. I have tried to grok the AWS IAM documentation but I got lost very soon.


Yeah, I've been on that side of it as well and also didn't find anything. Feels like something that could even be formalized into a standard and make things a lot easier and more secure for everyone.

IAM in AWS is mostly for internal permissions, to implement principle of least privilege within your account. For user accounts, look at AWS Cognito. I believe they have SAML and Google based login options, or you can implement your own. It's kind of convoluted to get your head around but it is pretty flexible and powerful (like most things AWS).


here at Liip, we usually tend to give people full access, so roles are not so relevant, except for my wish to have "billing users" so that we could create a 3rd party like cleanshelf a billing account so that they can extract only the data relevant to their service.

Beyond that I really love the usage based billing approach of Slack, where we could just give all our employees access and we get billed on how many actually use the service. Access would be managed via Google Auth or SAML.


Your point 4 has quite a problem with incentives alignment. You expect the SaaS vendor to spend resources in order to minimize your payment to them - their revenues. I can see why that would be somewhere among the lowest priorities.

Also, point 6. I understand where you come from, but you should also understand, that you are using release shared by several/many customers. If everyone had a veto power over rollout, nothing would get rolled out, at all. Therefore, if something gets broken, use your SLA, it is much easier to fix a specific bug, than delay the release.


On contrary, if there's no anxiety over unused accounts, clients might more easily buy larger plans.


With point 1), I agree.

Point 4, depends on granularity. If it was on user/month basis ala GApps, then it might be workable.


This is a great list of points, and amusingly it looks a lot like our issue tracker for Cronitor.io in 2015-16.

I think it’s worth pointing out that these things are not trivial to build and maintain. Even those items on our roadmap already are unlikely to be pritorized over product improvements unless we have a customer specifically request it. Hour for hour I think I can add more value improving product and adding features compared to, for example, billing workflow improvements.

Also amusingly, liip.ch has a free Cronitor account and emailed support asking that we add an integration similar to our PagerDuty integration. Our reply was basically what I’m saying here: we would be happy to build this during your free trial if you’re willing to take that step and put in your billing details. Absent of objective ways to weigh one feature against another, “is somebody willing to pay for this” is usually enough to win the argument.


Although that's nothing too extreme, I kinda feel like you shouldn't be leaking info about who is and isn't a user of your service, and what support requests they've been making.


Our standard terms of service include a clause for Promotional disclosure. Users can opt out.

I do appreciate your feedback and I’ll edit that comment to remove the name of the vendor integration requested.


You consider sharing internal ticket information “promotional disclosure?”

You might just want to delete the original comment; it was an incredibly poor decision and demonstrates a frightening lack of professionalism.


> You consider sharing internal ticket information “promotional disclosure?”

Yes, I think it’s fair game to discuss feature requests to a saas business in the comments of a story about feature requests to saas businesses.


Ideally your terms of service wouldn't be a tool to wield against people who don't have time to read it.


Sorry you feel it’s being used that way. We’ve literally never had a complaint from a customer about this, but it’s nice to know that people with feelings as strong as yours about this exist so we can be sensitive to it.


>Sorry you feel it’s being used that way

I am still willing to agree to disagree (your service, your ToS, your customers, etc.), but 100% certain the blatant nonapology is better skipped in the future.


You should be happy to get that kind of feedback! People who read terms in advance will disqualify you because of terms like that.


Points 5 & 6 are basically requests for change management (https://www.enterpriseready.io/features/change-management) features. This is SOOOO often overlooked by SaaS vendors.


I agree with a lot of what this says... this one in particular:

> Lack of PDF invoices

Seriously!?! Your target market is business they need receipts. I even have one service I have considered dropping because they have no receipts at all.


Source of my all-time favorite @idlewords comment (https://twitter.com/Pinboard/status/558306932575207425):

Many European customers end up asking me for a formal invoice. A wonderful teaching moment about sending money to some dude in California


I use this one as a way to differentiate Big Enterprises from small companies.

My thing costs $10/month. But we have a $300/month Enterprise plan that gives the same thing plus PDF Invoices, Purchase Orders, and a few other things that only large organizations with Accounting and Purchasing Departments need.

Those organizations tend to be fairly price insensitive, so the two numbers I listed above both round to zero as far as they care.

Problem solved for everybody.


Tell me about it. Whenever I hand in an invoice from one of those US services, I get strange looks from the accounting desk - even the receipts of established, large US companies barely pass as legitimate invoice, often featuring little more than a date, email and amount due.


That's because invoices and receipts are different things (at least in the US). You typically get a receipt for a monthly credit card payment. An invoice may be an extra that is only offered for example with an annual contract, and may even have to be manually generated, and typically implies payment made separately (NET-30 etc.).


Pinboard had a really funny tweet about customers being angered he doesn't send invoices.

When someone asked for one Maciej just sent them a blank invoice template and said to fill it out themselves. If I remember correctly it just made the guy madder.


For startups using Stripe, they can send receipts, and many companies like Quaderno exist to fill the gap as well.


It's not a gap, it is laziness or lack of attention to detail. It is a day of work to add invoices. Less depending on what services you use.

Yet many companies don't even do that. But even so, that should be the bare minimum they do.

PDF invoices have distinct advantages over email. Mainly that most companies still aren't using expense reporting and accounting systems that can process email receipts. Most people still have to upload their receipt to a website. If it comes in as email that means:

- Printing as PDF

- Then uploading

It is an extra step that is completely unavoidable and doesn't seem like it would be an issue until it takes an hour+ to complete your expenses because a dozen web services force you to do this.


> the total lack of configuration management

Yes please. I only want the following for Christmas: free testing environments (enforced with data being wiped out every week, perhaps), a way to provide a Git repo with the configuration, a way to define the branch in that repo which should configure this particular instance, and a way to provide read-only credentials for that repository.

> test out new features before moving to production

Configuration management is not version management. If you really want to manage versions, run a private instance (on-prem or in your VPC, doesn't really matter). The whole point of SaaS is that the SaaS vendor takes care of upgrades for you and that you're not thinking about it (because you have other work to think about).


Slightly OT, but SaaS vendors without clear upfront pricing are also a no go for me. Oddly, cleanshelf (which got recommended by the OP, perhaps affiliated with?) doesn’t have a pricing page I could find...


Thanks for the feedback. At Cleanshelf we primarily focus on mid-size companies (100 to 1000 employees) and there it's important to understand the business needs before we can discuss pricing. I hope you understand.


I read that as "it's important to understand how much we can gouge you for".

Sorry, I wouldn't even consider using a service that isn't up-front about pricing.


Is that a nice way of saying "we need to figure out how much money we can get from them"?


just to clarify, Liip is not affiliated, we don't get any kick-backs and generally we do not accept kick-backs anyway (if we do get a kick-back for one of our customers, we hand that kick-back to the customer), specifically because we don't want to recommend something simply to get direct financial gain.


The idea of versioned configuration is in part a result of gui-driven configuration. If you can configure via text file, then configuration can be versioned via standard version control mechanisms. Otherwise, you're going to wind up with something half-assed.

I had a lot of insight when I started using Concourse CI. All CI workflows in Concourse are straight-up yaml files - no gui anything. This is such a different experience from almost entirely gui-driven systems like Jenkins.


If your SaaS already have an export option for the configuration, it shouldn't be that hard to versionize it as well. You could intercept all database calls that change the configuration and just save a copy of the current one. This can be done in many ORMs already.


I wish he would cite more examples of what SaaS services he might be referring to. As a developer I am not aware of what mistakes competitors might be making.


These are good points, especially about the invoice PDFs and a way to send them automatically to a certain e-mail.


I'm yet to find a service that allows you to configure two email addresses - one for accounts related notification (your credit card is about to expire/your card declined etc) and one solely for sending a copy of invoices.

We use reciptbank (that has an inbound email address for forwarding invoicss to) for invoice processing into our accounting system.

Currently invoics go to our accounts@ email address (along with all other accounts related stuff) and the invoice specific emails are forwarded onto receiptbank manually.

Would love to be to tell the saas platform to split that out into two different email addresses.


Why not set a forward filter based on the subject on your end?

Been doing that for years...


Could do (and have in the past). But it is a workaround, and takes extra effort.

A couple of our suppliers do have the separate-email-for-invoices-only thing, and it really is super convenient to know that any changes they make to their invoice emails (subject lines etc) won't break our forwarding rules.

Also the forwarding rules don't survive email migrations (which I admit is a super infrequent thing to do). When we migrated from Google Apps to Office 365 we lost the rules we'd previously set up for this type of thing.


I’ll second these wishes. It’s actually a huge pain to hunt for the invoices/receipts every month for number of services. With the email option they could go directly to accountant.

Not sure how it's in US, but in those few European countries I'm familiar with you need a proper receipt (showing what was bought, VAT etc) for bookkeeping. Credit card statement is not enough.


In the US there are ~0 rules about invoices. I'm in the middle of implementing EU-compliant invoices for a US-based SaaS offering and boy, y'all need to chill about all this.

Launching the actual product was easy. Complying with EU rules has been the nightmare.


VAT (Value Added Tax) is the main reason why EU is more strict about invoices than US. And these rules are there for a good reason given many different ways how VAT system can be exploited.


What are those reasons? (Seriously asking, not being snarky)

The US has sales tax but doesn't require any of these rules around invoicing.


It mainly revolves around the facts that 1) VAT is deductible for companies in certain cases 2) Companies are responsible for collecting the VAT for products they sell and submitting the collected money to the government. These things mean that auditors (and in some cases officials) must be able to verify that VAT has been collected, paid and deducted correctly. Therefore it is important to have receipts which clearly show who sold, who purchased, what was purchased, what was the price and how large portion of price was VAT.


Nice list for a B2B SaaS. We ( https://tasksinabox.com ) are certainly guilty of 5 and 6. I'll bring it up with the team.


This is a nice list, though not all of them take into account what specific features will help a company grow / generate revenue / reduce complexity.

For example, change management and by-use billing and/or monthly billing don't go hand in hand. If you want something like change management, it'll be a serious investment, not a piece of software you pay $50 / month for.


I agree it's a mess. However, most SaaS vendors realize that the people who have to clean up after them are often not the people in charge of the purchasing decisions. If you end up paying them for years merely because you can't find a way to gracefully exit, they do not consider that to be a poor outcome.


Interesting list indeed. At my company (saas provider, ~60 people, B2B learning platform, ARR in millions), we are considering providing a test environment to enable our users to test our new features (we deploy new features every ~6 weeks).

One thing that make us reluctant to do this is that we doubt people from our B2B users will put the time and efforts needed to fing bugs in a disposable test environment.

I'm really interested in learning the best practices to "battle-test" a new release for our current stage. Because for now, gradual feature deployment "à la GAFA" looks way too expensive at our stage (deploy to 1% of the user base, get feedback, fix bugs, proceed to 10%, repeat, and finally 100%).


Put feature flags around new features, add a “show beta features” setting. Allow people to opt-in.


Interesting. I’m giving a go at building a SaaS product on top of erpnext. Many of his requests are covered by default functionality.

And, while the documentation for erpnext isn’t the greatest, it largely just runs WSGI apps with an interface to the underlying ERP.

I’m attempting this route, because information management becomes a nightmare across 20 applications and 5 users at a 20 person company.


Agreed entirely on auto suspending inactive users. Testrail by far are the worst with this, we added a bunch of users by mistake after our JIRA configuration went a little... over the top, got an enormous bill for two months and despite us never logging in they refused to refund.


Receipts is a huge one for me for services I use as a Business. Even better is VAT receipts. My most frustrating is Backblaze as what they provide is next to nothing other than a transaction entry. So every month I print it to PDF and it's just a rolling total for that year.


> One of the several holacracy roles I have at Liip is called “Platform Gardener”.

Is calling something a gardener enough to keep it from being management?


no .. but we choose this different terminology because management is usually associated with decision power, where as explained in the blog post, I just help people get whatever they decide themselves.


Being able to use LDAP for authentication would be nice for a few services.


You don't want to use LDAP over 'net, foreign services have no business to bind to your LDAP. Use SAML or OpenID-Connect, they do not expose things that should not be exposed. If you are using them consistently, you will get SSO.


SAML is kind of the solution that is now pretty well supported in the SaaS world. So you "just" have to setup a SAML provider with your LDAP for authentication.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: