It's worth noting, you cannot do any form of fixed fees without a defined scope of work in writing. Spending a little longer initially to clearly outline your Services will allow you to manage scope creep more easily.
Service descriptions are critical to defining the scope of work you are delivering and should include at least:
what you are doing for your client
be specific and use terminology your clients will understand by avoiding jargon and internal terminology
e.g. "reconciling credit card and chequing/savings accounts"
when are the above deliverables received by your client
note: recurring deliverable frequency can be different from the billing frequency
e.g. weekly payroll, AP/AR, bank reconciliation can (and should) be billed monthly to reduce admin
quarterly and annual services can (and should) be billed monthly to provide billing consistency and a steady revenue/cash flow
programs your client will see and interact with as this service is being delivered
e.g. "We will use QuickBooks as the general ledger and your subscription is included in the price of this package"
of course, if the client doesn’t see or use any software with the service in question, you don’t need to mention it
setting caps on your deliverables are key to preventing blowouts and managing scope
e.g. "We will reconcile 250 savings account transactions per month"
consider a tiered approach to provide consistency and flexibility, e.g. "Payroll for up to 5/10/20 employees"
Remember: these do not have to be hard and fast rules. You can treat them as a guideline and agree to adjust the pricing if these limits are consistently exceeded (e.g. over a 3-month period)
Here's an example of what a service description might look like for a monthly bookkeeping service:
Click here for our how-to guide on setting up your Services.
Comparing a well-written service description to a poorly written service description:
An example of a well structured service
Service Name: Weekly Payroll for 1-5 employees - Gusto
Service Description: Payroll for up to 5 employees. We will run pay on a weekly basis. Payroll will be run on Gusto and your subscription will be managed and paid for as a part of this service.
This is a good service for 2 primary reasons:
1. You have clearly defined what is going to be done so you will need to make minimal changes when you add the service to a proposal, making your build times faster.
2. Because your service is clearly defined the default pricing will be more accurate and you can maintain your pricing consistency.
An example of a poorly structured service
Payroll for up to *<< employee_count >>* employees. Payroll will be run on a *<< payroll_frequency >>* basis. We will use *<< payroll_system >>* to run the payroll.
This is a poor service for 2 primary reasons:
1. You will have to make many changes on the proposal level as you add it, increasing your time to build each proposal.
2. Changing the service description and price each time makes it difficult to keep price consistency and makes segmenting clients and reporting more difficult.