Dear SaaS vendors
liip.ch
liip.ch
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.
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 might also want to check out figo and fidor.
[1] https://gocardless.com/faq/merchants/international-payments/
[2] https://gocardless.com/faq/merchants/
edit: link #2
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.
In my experience, it's a lot more common and accepted than credit card business payments in Europe.
Opportunity, business idea seekers!
Would you share more details about this, if you can?
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...
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
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.
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.
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).
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.
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.
Point 4, depends on granularity. If it was on user/month basis ala GApps, then it might be workable.
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.
I do appreciate your feedback and I’ll edit that comment to remove the name of the vendor integration requested.
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 might just want to delete the original comment; it was an incredibly poor decision and demonstrates a frightening lack of professionalism.
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.
> 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.
Many European customers end up asking me for a formal invoice. A wonderful teaching moment about sending money to some dude in California
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.
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.
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.
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).
Sorry, I wouldn't even consider using a service that isn't up-front about pricing.
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.
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.
Been doing that for years...
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.
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.
Launching the actual product was easy. Complying with EU rules has been the nightmare.
The US has sales tax but doesn't require any of these rules around invoicing.
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.
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%).
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.
Is calling something a gardener enough to keep it from being management?