about to get into my first one - do you have conce...
# suite-billing
k
about to get into my first one - do you have concerns?
s
Definitely have some concerns - I'm wrapping an implementation now and have had to solve some issues. Nothing deal breaking but definitely not widely mentioned.
For example - if you are invoicing subscriptions and sales orders together, Subscription will create its own invoices separate from Sales Orders. This may be confusing for customers who are used to getting one invoice for software and hardware/PS.
Same for revenue merging - you will need merge related subscriptions and/or Sales Orders, then allocate. For example you sell hardware on a Sales Order and maintenance on a subscription - revenue allocation dictates that the FV of maintenance should be 20% of Hardware. You will need to merge the SO Arrangement with the subscription's arrangements.
Separately, there's a rigid pattern for item configuration of items for subscription plan and associated revenue rules. This is detailed out in SuiteAnswers but it does force you conform to NS's way of selling. You can work around it but have to get a little creative. This goes back to the concept that NS ASSUMES how you do your business - that you have an exact selling catalog and you are fairly uniform in how you sell. Customer specific catalog can be achieved but can get messy.
Currently, termination of subscriptions do not translate to termination of revenue immediately. Depending on your business, it may need to be managed manually. NS also "enforces" co-termination of subscription lines on the same subscription. We have not found a workaround yet within the same subscription, but you can book a separate subscription with a different start and end date.
Finally, data conversion is the most tedious part and depending on which approach you take, you will get a faster implementation but lower return on value of implementation.
If you have approval requirements for subscription Change Orders, currently there is no "pending approval" stage for new Change Orders (which have revenue impacts).
All this to say, I do prefer SuiteBilling over nothing (i.e. vanilla SO and billing schedules or SFDC CPQ). There are potentially better alternatives but we chose SuiteBilling because it is much more flexible in how it interacts with ARM. Renewals automation can be awesome and built in price uplifts can be scheduled out at the onset of the subscription price book.
k
@suitetastic - thank you for such detailed notes! helpful! I wonder if you considered Contract Renewals modules and if so why you selected SB vs CR?