|
|
|||
|
|||
|
Hi,
I'm wondering how others are handling MSP contracts in Commit, in particular for "All-You-Can-Eat" (AYCE) clients? My goal is to be able to send the client an invoice for their monthly maintenance along with a list of tasks performed each month (tickets). For internal purpose, I also want to tabulate labor spent on each contract. For the base monthly contract, I've got a recurring contract with a "Contract-price Charge". That seems fine. But what about the tracking the time that I put in to each contract? I set up a Labor item called "MSP_SysAdmin" and a Fixed Rate of $0.00. I don't see any way to define the Item as non-billable. And whenever I create a charge based on this item, whether it it Billable or not, I get a popup "Not entered Price/Rate - Continue?" Am I doing this right? How do I tell CommitCRM to allow non-chargeable services without giving me a popup every time? Mark |
|
|
|||
|
|||
|
Hi Mark,
Thank you for your question. The best way to manage all-you-can-eat contracts is using a Block Of Money Contract in RangerMSP. You should create a monthly Block Of Money Contract, and set the block to the amount the customer pays each month (probably the same amount which appears in your Contract-price Charge). The nice thing about this type of contract is that each time you enter a charge against it, this charge will be automatically marked as "not billable", as the system assumes it is covered by the contract. In addition, the amount in the charge will be reduced from the block balance, so you can track how profitable this contract is. This way you can enter the charges with the regular items you use anyway, set their price like always, and have them set as "not billable" so they will not be billed to the customer. You will be able to include these charges in reports and in invoices, so you can show the customer all the work which was done for this contract. You can find more helpful information on contract management on our Web site here. I hope this helps! Doron |
|
|
|||
|
|||
|
We assign a "standard" internal accounting rate to the item that you call "MSP_SysAdmin". CommitCRM then does not complain about a missing rate.
Your CPA can help you determine what your "fully burdened" internal rate is. That is, an internal rate that includes wages, taxes, share of office expenses, etc. Then at the end of the month you can get a reading of the profitability of the fixed price contract. |
|
|
|||
|
|||
|
Thanks to both of you.
Allen, I doubt my CPA would recognize me; I haven't seen him in four or five years ;). (Most of my accounting stuff as a sole proprietor is pretty simple and repetitive.) But you raise an interesting point: you're suggesting to set an internal rate for my time vs. the rate I would charge a customer if I were working hourly. So that means: - I still need separate "Items" for MSP time as opposed to the commingling them with the "regular items you use anyway." - I should theoretically be able to check my REAL profitability as opposed to "how much am I making/losing compared to billing this by the hour." Right? Mark |
|
|
|||
|
|||
|
Well I tried a $1.00 contract and it keeps nagging me about it being out of funds.
Now I'm trying to enter a change for a block of time, from 9:15PM to 12:50AM. Found out that you're not allowed to work past midnight. So I tried entering two charges, and it seems you can't enter 12:00AM as a start time either--it keeps blanking it out. |
|
|
|||
|
|||
|
Actually, for pro-bono contracts I would go about it the other way around - create a block of money contract, and set the block to a very high amount, to make sure you don't reach the block limit ever. This way you can log as many charges as you wish without the system alerting you about the block limit. Note that setting the contract block does not have any billing implications (only if you add a Contract-price Charge, this will appear as a billable contract). I hope this makes more sense now.
As for entering charges which span over midnight, the system prevents this, and this is actually the expected behavior in this case, as this requires two separate charges. There are many reasons for this, for example, how a multi-date charge should be handled when it related to Contracts that expires on this day (and the new day is not covered by the Contract)? To what date do we need to consider this work when printing employee activities reports when it spans on different weeks or months? There are many other questions/issues that this may cause, and the system currently lets the user make these decisions manually. What you should do is create two separate charges, one for each day (on until 11:59, and one from 12:01). Note that you can create the first charge, and then copy it and change the time. It is very easy to copy a Charge record to the next one by right-clicking the charge and selecting the Copy option. All the charge details will already be selected including the Account, Ticket, Contract, description etc. I hope this helps. Doron |
|
|
|||
|
|||
|
Okay thanks for those explanations and the tip on copying hours.
While we are clarifying contract options, perhaps one more question: how to handle the client that gets x hours for a flat fee, then pays and hourly rate over that. Do I need to set up a Block of Time contract _and_ a Global contract, charging the initial time to the first contract, and additional time to the second? |
|
|
|||
|
|||
|
Yes, that is one possible option to go about it. the benefit is that when you work with the global contract, these charges will be automatically marked as "billable".
Another way would be to use the same contract all along, but set the charges which are over the block limit as "billable" manually. This way you will be able to easily see how much time was spent over the block limit. This can help you analyze the block profitability for the customer, and maybe offer them a better deal next time... Doron |
|
|
|||
|
|||
|
Back on the all you can eat scenerio....
The instructions for How to use Recurring Contracts says to use Contract-price charges to automatically bill the customer for the new contract. Our all you can eat is a flat rate on a per workstation and per server basis. What type of item should we be adding to this tab in this case? One line item for the total price of the contract? One line item for workstations with the total qty and another line item for total servers? Would these be product part charges or labor items? |
|
|
|||
|
|||
|
ascendnet - I believe you can do this in various ways, like you suggested, depending on your specific needs.
Basically, in order for the contract-price charge to be flexible, I would suggest adding an item, which represents a single workstation price per month, and an item for a single server price per month. These items can be Labor items, which are unit-based (rather than based on hours). Then you can add one line for workstations and one for server (as you suggested), and each contract-price charge will include the quantity of workstations/server which are covered. Whenever this number is updated (e.g. if the customer wants to add an additional server), you can update the contract-price charge, and the new quantity will be reflected next time you renew the contract. You may find some more examples for different ways to use the Contract-price Charges in the user guide in this section. I hope this helps. Sherry |
|
|
|||
|
|||
|
I've got a problem with using the all you can eat contract the way you describe with using a block of money. Lets say a technician creates a ticket, goes onsite, performs work, adds his labor to the ticket, then adds a part that is needed to the ticket. When the part is added to the ticket the part is not set to billable.
What I'm describing above seems to be doing what we've told it do, mark all items as non billable and warn if going over a predefined dollar amount. Because of this I'm not sure block of money is the best route to go for MSP services or All You Can Eat programs. These are typically labor only contracts and do not include parts as well as other labor items not covered under the contract. I know we can tell the techs to click billable on the parts or services not covered but it is inevitable that this will not always occur and when it doesn't it can be a VERY costly mistake. Have another suggestion for us? |
|
|
|||
|
|||
|
Hi,
Thanks for the additional input on the way you implement this at the moment. This is interesting stuff. I believe I can suggest a way to implement an "all you can eat" contract in a slightly different way, which includes only labor (parts not included), and I hope this will work for you. The block-of-money contract, which was suggested previously serves well in case all is indeed included, labor, parts and expenses. Perhaps in the case you describe, it would be better to use a different type of contract. What you can do is use a block-of-time contract in this case, and set it with a very high "hours" block (there is no real limit here, so you can set it to a very high number, to avoid reaching the limit). Each time a technician enters a labor charge against this block, it will be automatically marked as not billable. However, Product/Parts or Expense charges are not covered by block-of-time contracts, and therefore they will be automatically marked as billable. This way your techs will not need to remember to set these charges as billable or log them against a global contract, as the system will automatically take care of this. You can still use the Contract-price Charges in order to reflect the kind of service you provide in this contract and the price, as explained previously. Only the management of the "regular" charges will be affected by this change. I hope this makes sense. Doron |
|
|
|||
|
|||
|
I think we're close but there is still the issue of some labor is not covered under the contract. Lets say we have a maintenance contract that includes software updates/installs but does not include hardware installation. I would like to be able to assign a maintenance contract to the account to handle this.
A tech goes onsite to perform software maintenance on a system and also install a new video card on several other systems. He performs the maintenance then adds a labor item called maintenance to the ticket with his time, which is not billable. Then he adds a hardware install item to the ticket for the video cards which should be billable. I'm trying to find a way for the contract to be created where the contract will define what is billable or not billable. I know we can tell the tech to change the contract to something else like global or mark the charge as billable when adding the hardware install.If we rely on the tech to make these decisions they will not always happen properly. |
|
|
|||
|
|||
|
I see what you mean... Sounds like you would want some advanced contract customization options (per-item customization) which we may look into in the future. At the moment, the charge behavior is determined according to the contract type. This does provide quite flexible options, and I believe that in the case you are describing, you should probably just use a different contract for the charges which are not covered by this contract.
Thanks for your interesting feedback on this. Doron |
|
|
|||
|
|||
|
I finally got a chance to read through this thread as there are issues being discussed I haven't come across yet. The one thing I'm unsure about is - Can you make an item under a block of money contract billable if the labor isn't? Is it as simple as checking it as billable?
If that is the case, I think this is a technician process/training issue. There is no way I would want to have to go through each contract and modify whether a part/item is billable or not under that particular contract. I think this may be why the somewhat tedious individual invoicing process you go through in CommitCRM is a good thing. It forces you to review your charges prior to invoicing. --AJ |
|
|
|||
|
|||
|
I have the same problem. I am constantly double checking people to make sure that parts or "non-contract" labor didn't get stuck under a "AYCE" contract. It would be better if you could force a user to CHOOSE a contract every time instead of having the system try to figure out what you want to use.
This is an area that would be great to see some improvement in. Luke |
|
|
|||
|
|||
|
Mark,
But then that means that I have to create a second "dummy" contract for all of my managed serices clients. So it would mean a new "dummy" contract every month. That's not very efficient and it is also very "cluttering." Plus, once you choose the contract for the ticket, the same contract populates to the charges for that ticket, if I'm not mistaken! See what I'm saying? Am I missing something? Luke |
|
|
|||
|
|||
|
Seems to me that most MSP's have a contract with their clients similar to the following. I understand this isn't the exact for everyone but it's a starting point.
Maintenance Contract Includes: System maintenance (Temp file cleaning, defrags, etc.) Operating system updates Remote Support related to the above Does not include: Software installations (Labor) Hardware installations (Labor) Software (Parts) Hardware (Parts) Onsite Support (Labor) I like some parts of the suggestion from CommitCRM to use the Block of Money contract because I can easily see how profitable a contract was or if we took a loss. What I don't like is that by default every charge gets marked as not billable and just counts towards what we set at the block value. In reality though this is doing exactly what that type of contract is for. What I think we need is a contract where we can add a list of items that are included as part of the service. If a charge is created with one of these items it will not be marked as billable. If a charge is created with an item not on the list it will be marked billable. This way the contract is defining what is billable and what is not. All the tech has to do is create a charge for the item and move on. This would be similar to the custom pricing tab but you would be defining non-billable items instead of a custom price. We don't want to have to constantly switch what contract is on a ticket or charge. It would also be helpful if we set it could have some of the features of the Block of Money contract. On the block of money contract you can define the value of the contract and easily see how much was used. It would be nice to see something similar where we can define a value for the MSP Contract and see the dollar amount of non-billable items that were attached. Thoughts anyone? |
|
|
|||
|
|||
|
It would also be cool to be able to say what quantity of the specified item was included in the contract. For instance, if you were doing all the maintenance, patching, backups, etc plus two hours of remote support or something like that... It doesn't really make sense to do a block of time, because you are doing more than just "time." You are providing other services, but including a set amount of time (or perhaps other items) with those services.
Luke |
|
|
|||
|
|||
|
Luke,
I must be missing something. You first asked, "It would be better if you could force a user to CHOOSE a contract every time." But then you say you don't want to link multiple contracts to the account. What are they supposed to choose from, if not from multiple contracts on the same account? I'm still new to Commit, but is it really more work to copy two contracts forward at month end rather than just one? I can see the attraction in more flexible contracts. Maybe we're moving towards a concept like a "super-contract" with any number of subordinate contracts of different types? Mark |
|
|
|||
|
|||
|
Mark,
It sounded like what you were saying was creating a "dummy" contract so that there would be two contracts for the date range - thus forcing CommitCRM to not choose a contract automatically. My point is... That's a hack, not a fix. Yes, that works, buy why do I want to have dozens of "dummy" contracts filling up my contract list? That seems like it would be very confusing. Sure, you could label them so you would know, but it is still ugly. Maybe I'm too much of a perfectionist. It wouldn't be hard to for CommitCRM to add the feature of "forcing a user to choose a contract." That's what I'm proposing. In the mean time, we can work with it! Thanks for your help! Luke |
|
|
|||
|
|||
|
Commit, Does that mean you have nothing more to add in regards to a solution we can use now? I only ask because I have been holding off on creating and applying contracts because I could not find a way of doing it and was hoping you or another user would have a good way of doing it. Thanks |
|
|
|||
|
|||
|
Hi ascendnet,
I believe the options which already exist in the application were covered along this thread. This doesn't completely cover the specific scenario you have described (in regards of the MSP contract with specific labor and parts items not being covered), and this is something we have noted for us to check how we can cover this kind of use case. A fully customizable contract (which lets you define how each item behaves) is something which is on our radar for a while now, and has been mentioned in the past. At the moment, you may consider tracking items which are usually not supposed to be covered by your MSP contracts, using Charge reports. You can filter the report by the item, and by the billable flag, and see whether you have non-billable charges with this item which were logged this way by mistake (i.e. should be "billable"). This is not a fully automated solution, but should help you make sure you don't miss on any billable items. I hope this helps. Ethan |
|
|
|||
|
|||
|
I'm curious about this statement:
Quote:
I know you've promised better email handling in 5.2 or 5.3... That's great, and I'm looking forward to it, and I appreciate your responsiveness to the community. Thanks, Luke |
|
|
|||
|
|||
|
Those are also the two biggest items I need here as well. I am currently trying to put into place workarounds for my MSP contracts and it takes alot of work to create them. If I knew the contract update would be a month or two out I probably wouldn't bother with the workarounds and just wait.
So any timeline would be great. Thanks |
|
|
|||
|
|||
|
Thanks for the follow-up. As you mentioned, Luke, the enhanced Email Threading is currently planned to be added on in the next release (we may release a mid-term release with other features earlier, or release all new features, including the threading, in a single release, it hasn't been decided yet). As for the the enhanced contract options - this is not something which is currently being worked on, we will probably get to it in one of our future releases.
Ethan |
|
|
|||
|
|||
|
You know, would it be possible for us to see a feature timeline? If we could, I bet you guys could get some good feedback on what was important or not to your users! I know you are probably afraid of saying you will provide features, and then not delivering and making people mad... I think it would be helpful.
--Luke |
|
|
|||
|
|||
|
Thanks guys, we will seriously re-evaluate this idea, we still need to find the magic combination... The feedback we get here and directly by email is great and guides when we prioritize our tasks. In any case, I can say that the main feature that we're currently working on is the enhanced email threading - a capability that was strongly requested in other forum threads. The solution consists of several aspects and we're moving in that direction.
Besides, we're working on some other enhancements, some will serve as the building blocks for the enhanced threading, some will just make the system work better. We are currently considering releasing a mid-term version, before the enhanced threading release, this will enable us to release new features instead of holding them until the major threading release. Thanks, Sherry |
|
|
|||
|
|||
|
Commit,
Can we get some kind of time frame on when better handling of contracts will be coming? We are going all Managed Services and the current way that CommitCRM handles contracts is not going to work. I really want to stay with CommitCRM but if this is going to be more then a few months out I'm afraid I might also need to look at Connectwise or TigerPaw. Please don't take this the wrong way. The two things I need most from CommitCRM are better email integration and more options for contracts, especially ones geared toward managed service providers. The email is definitely moving the the right direction and I'm hoping that the contracts shouldn't be too hard to enhance. Thanks in advance |
|
|
|||
|
|||
|
Hi,
Thanks for posting this great feedback. The RangerMSP system has some options for MSP management that we wanted to make sure that you were aware of. When using all you can eat contracts, we suggest using block of money contracts, so that you can better monitor the profitability of the contracts that you offer your customers. Each Block of money contract can have a single price that gets charged to the customer in the Charges - Contract Price tab, while all other charges that are created (save product/item) created in the Charges tab will be marked as not-billable by default, but always subject to your own digression. The [hightlight]Email Connector [/hightlight]can be configured to take most MSP software tickets, and create tickets for your customers in RangerMSP, while online asset monitoring and remote desktop services can be configured to be run from RangerMSP using the customizable [hightlight]Online Services [/hightlight]tools. We release several new versions of the software that include new features and enhancements to existing features which also include topics mentioned here in this post; since our features are mostly decided based on popularity. We wish to express our appreciation for the quality of the feedback submitted in your comments, and for letting us know how we can make RangerMSP better for your business workflows.
Thanks again guy... Reno Breen |
|
|
|||
|
|||
|
Hi Reno,
Please read through the thread and you will see why the block of money or any of the current contracts really don't work well for MSP's. I think my post on July 21st, 2009, 11:42 AM describes a great starting point by just adding one or two new contract types. All it would have to be is similar to the existing Block of Time or Block of Money contracts with the addition of a list of items that are or are not billable. That way we never have to rely on whether or not the tech properly checked or unchecked the billable box. It really isnt the job of the tech to make those decisions anyway. |
|
|
|||
|
|||
|
Hi guys,
We're a customer driven company at all levels and provide a customer driven product at a very reasonable price. As we said plenty of times - all feedback is noted, we learn from it, appreciate it and try to implement the best system for as many users as possible within each release of our softtware (our growth teaches us that we must be doing something right). Obviously we can't implement all requests (I guess this is always the case with software products) and some other requests are put on hold so we'll be able to focus on other highly requested features. Doron |
|
|
|||
|
|||
|
Where are things at with improving the functionality of contracts in CommitCRM with some of the items discussed in this thread? About 90% of our business is done with clients that have some type of contact with us. I would love to be able to use them but they just don't work well.
|
|
|
|||
|
|||
|
ascendnet,
Thanks for following up on this. The ideas and comments in this threads are valuable and are currently high on our list. We will be implementing some changes in one of the coming releases, not in the next release, 5.5, though (more on this will be published separately when we have more info), but anyway, as you've probably noticed we've changed the way we release new versions recently so when I say that it will be implemented in one of our coming releases it means that it's not that far. Thanks, Neta |
|
|
|||
|
|||
|
With the importance of how the contacts work can you setup some kind of group to go through what you are thinking of doing vs what we need with how we do business? I really want to make sure that the contracts fit our needs as I'm sure others will here will say as well. I would hate to just have contract enhancements come through and miss some key piece and then have to wait for the next round of enhancements to them.
If you setup some kind of panel to dig deeper into how we provide our services and contracts it would be extremely helpful in the development of this important function. Also in regards to the mention that it would be in one of the coming releases can you get a bit more specific on this. That is kind of the standard answer around here and I need to find out an estimate of what this means. Thanks |
|
|
|||
|
|||
|
Thanks ascendnet,
I believe the content of this thread is what will guide us with on what to implement, so if you feel the above doesn't cover your requirement please post additional information. We don't have the final design yet as we're working on other stuff at the moment, but in short I believe that it will provide you with the ability to create a Contract where you decide default Billable/Not-Billable values for the different types of Charges. We may be able to share more details when we have them. Our current plans fare to continue releasing new versions every 2 or 3 months (last release was only 6 weeks after the previous one has been released), so I would say it's probably a few months away. Thanks, Neta |
|
|
|||
|
|||
|
I'm going to have to go through the thread again and compare it to our contracts, want to be sure that nothing was missed.
One thing that I can add though is that the contract needs to have a tab where we can specify the assets that the contract covers. Contracts typically either cover an entire site or specific computers at that site. When a tech works on a ticket and adds an asset to it the contract drop down should update to only show the contracts that apply to that asset. Along those same line we should also have an asset tab on a ticket. We frequently work on more then only system on a ticket. Same with the charge window, should be able to add one or more assets to a charge. |
|
|
|||
|
|||
|
It's been about a year since this thread last had any activity so I figured I'd bring it back to the front page again.
We too are struggling with setting up our first AYCE contracts in CommitCRM and the ability to have a custom contract where we could simply define which specific items were and were not billable as well as to define which items do or do not deduct their value from the block of money (ie: if an item is used for a part that will be set as billable, it shouldn't also deduct it's value from the block of money so it doesn't screw with our profitability reports, etc.). In my mind, here is how this could be implemented: The Custom Contract UI could have three tabs - one for each item type (Labor / Expense / Parts). Each tab would be a dump of the item names (and description if you see fit) with three simple columns of check boxes - Configure? Billable? and Deduct From Block?. Billable and Deduct From Block would be unavailable until Configure was checked. Various defaults and logic could be set for ease of use (when marking an item as billable it could automatically uncheck Deduct From Block of course allowing you to recheck if if you still wanted that functionality for some reason). I'll only get into that if you want me to. If a tech attempted to use an item on a contact that had yet to be configured a dialogue box should be displayed and this item would not be select-able in conjunction with this contract until it had been configured. The dialogue box could be something simple like: This item has yet to be configured for use with this contract. You must configure this item for this contract before it is able to be used. Configure now? Y/N Yes, takes you to the contract configuration screen no takes you back to the charge with the item blanked out waiting for you to select a different item. Alternatively, you could also choose simply not to display items on the drop down list that have yet to be configured with that contract. Might make things easier on techs as it simplifies the interface... but I'd be happy with whichever is easier to code :) If anyone else agrees with my description of this feature request, or has their own suggestions on how to change/improve it, please feel encouraged to comment :) |
|
|
|||
|
|||
|
Hi David,
This thread indeed lists some of the available options. You can learn all about this, and much more, by reviewing the different information listed here. I hope this helps. Dina |
|
|
|||
|
|||
|
Dina,
Thank you for your post. I have read all the information you pointed to and watched all those videos as well. I believe I can work around the issue by using the Block of Money contract as your videos have suggested for this type of situation. This leaves the burden on the tech to choose billable for products and could be a source for mistakes, which in my opinion is entirely what this thread is all about. So again, thank you for your post, but I don't believe your post answers my question. I am asking if CommitCRM still has a new type of contract that will allow labor to default to not being billable, while parts would default to being billable on the radar for an upcoming release. Thanks again for your time! David |
|
|
|||
|
|||
|
Hi David,
We may add a more automatic support for this in the future, in any case here's what you can do: Use the Custom Pricing feature in RangerMSP. It works at the Contract level. With this feature you can set the price/rate for Labor Items to zero at the Contract level. This means that when technicians log Part Charges under the Contract it will reduce the Money block while when Labor Charges are recorded they will default automatically to zero and will not affect the Contract block. Even if you're not using a Block of Money Contract you can use it. For example, with the Global Contract everything defauls to Billable, however, when used with the Customer Pricing feature you can set all Labor Charges to zero by default, very much like setting the Charge to Not Billable manually. I hope this helps. Dina |
|
|
|||
|
|||
|
What we really need to do for an MSP type of contact is to have a checkbox for “Not-Billable” when adding an item to the Custom Pricing section. It could be right on the same screen with the custom price, just an option to mark it as not billable.
For an MSP the items are charged to the client in one of the following ways…. 1) Billable – full price 2) Billable – discounted 3) Not Billable – Included as part of contract These really have to be defined on a per client or per contract basis. The tech should not be expected to make any changes to these types of charges and in most cases should not even have the permissions to do so. I really think you are going to see a lot more requests for this type of ability as more and more in our industry change over to an MSP type of business model. |
|
|
|||
|
|||
|
Thank you for posting this.
Enhancements related to MSP contracts and customizing contracts are planned to be introduced in our next release, at this time no ETA has been published. ***Update: In RangerMSP 9 we introduced Custom Settings for Contracts that provide much more flexibility when defining the Contracts |
