Sales and Business Development at OpenCraft is primarily driven by two forces: Strategic partnerships with existing clients turning into more work with them, and building a solid reputation for our services that ripples out into referrals who we then court.
That is not to say that advertising does not play a role in our overall marketing strategy, or that marketing overall is not important. However it does mean that our approach to handling sales and business development is in alignment with our values of openness, quality, and commitment. Of particular usefulness during sales is our quality of empathy: Not only is it important to understand how we can help our clients achieve their goals, it is also important to know when we are not the best fit for a client's needs.
We do not make promises we cannot keep. We set realistic expectations with prospects about what we will deliver, at what cost, and when. We are leaders in our field and do not skimp on quality.
Parameters for Sales¶
Most projects at OpenCraft are contracts from existing clients that have recruited us into a new venture. On the whole, we prefer getting more work from existing clients than recruiting new clients. The reason we prefer more work from existing clients is that each Client Owner is meant to have room for strategic planning around our relationship with that client.
Since each Client Owner is also a developer, and we presume that most developers want to develop, we work not to overload team members with too many clients. This provides a limit to the number of clients we can take, but ensures that the quality of advice we can bring each client, and the quality of life of each team member, can be much higher.
This means that whether we are open for contracts is primarily dependent on role load-- how many roles (including but not limited to client ownership) our team members have taken-- and whether more can be taken without pushing team members toward burnout. Capacity, defined as the number of hours we could dedicate to client contracts, is also a factor. However it is rarely a factor before role load is considered:
- A cell's role load is lowered as we hire more team members and close out contracts.
- Similarly, a cell's role load is heightened as team members depart and contracts are added.
- The Epic Planning and Sustainability Manager keeps track of their cell's role load, and advises the Business Development Specialist on when role load is light enough and there is spare capacity to take on more clients.
An Overview of a Sale at OpenCraft¶
Sales at OpenCraft can come through multiple vectors. The most common, as mentioned earlier, is starting a new project with an existing client. When a Client Owner or the Business Development Specialist identifies a new way for us to help the client, they can pitch the idea for Discovery. If the client agrees to spend the hours on Discovery, the Client Owner can either have someone on Discovery Duty take the discovery, or else they can schedule a task in the next sprint.
The other ways we get sales are through various leads-- some come through our website, some via referral, and still others through encounters in our community participation. For example, we might encounter a lead at a conference, or in a community working group. In this case, the client reaches out to us asking for more information, and we respond with an email giving a basic overview of OpenCraft and what we do. After initial exchanges, the Business Development Specialist schedules a meeting with the client and gets an overview of their project. Based on what the Business Development Specialist learns, they may assign a task to the person on Discovery Duty or schedule a task in the next sprint to perform a discovery.
After completion of the discovery, the Business Development Specialist integrates the figures determined by the developer into a full proposal document for signature, which is sent alongside the developer's discovery document. Here is an example proposal for an institution that wants hosting via our Institutional Plan, and also wants a custom 'Wormhole XBlock' to be developed.
The customer then reviews these documents, and, if satisfied, signs. If the client is a new client, the Administrative Specialist onboards the client. The developer who performed the discovery takes charge of the client's epic, and begins scheduling tasks, and the development cycle is underway. The developer who performed the discovery also becomes the client owner, if the client is new.
Prospect Intro Meetings¶
As part of qualifying leads and better understanding how we may meet the needs of clients, initial introductory meetings are scheduled.
Before the meeting, search for information on the client online. Most organizations will have a website where you can learn about who they are and what they do. Looking up the contact's information on LinkedIn is also helpful.
Things to keep in mind when looking up the client's info:
- Situation: What is the organization like? What do they do? Do we know of any trends or changes to their sector that may be affecting them?
- Problem: Based on what they may have already communicated, or what you can infer from your experience with similar clients, what kinds of challenges might they be facing?
- Implications: How might these problems be impacting what they're trying to accomplish as an organization?
- Need Payoff: How might OpenCraft be uniquely suited to addressing their challenges in a way that helps them be more successful?
Spend some time ruminating over this information and bring it to the meeting. You can quickly build rapport by speaking to their needs. Write up what you find in an update on the CRM.
While these meetings are fluid and should not have a strict structure, there are some helpful anchor points to keep in mind.
- If you're not sure how familiar the client is with OpenCraft, ask if they'd like a basic rundown of who we are and what we do. If they say yes, give them a basic introduction, going over these points:
- Our experience and knowledge of the Open edX platform
- Our involvement in the Core Contributors program
- Our commitment to Open Source
- A summary of clients we work with
- The volume of contributions we've made (and continue to make) to the platform
- Preferably, you'll have already read up a little on their organization. Ask them about it, especially any specific questions you may have come up with when browsing their website.
- Ask about the problem they're trying to solve.
- At some point in the meeting (if it doesn't come up in 1), be sure to mention our policy of upstreaming contributions. The earlier we can gauge the client's appetite for open source, the sooner we can determine their people profile, and whether they'll be asking us to work under terms we'll accept.
- If they have not tried Open edX yet, suggest that they sign up for the P&T trial so they can play with the software and see how it works. If you think it would be helpful, or if they've asked for a walkthrough, bring up the demo instance and show them around.
- Determine next steps and lay them out for post-meeting follow-up. This might be getting them to send a detailed list of requirements, or starting the discovery process. If starting a discovery, make sure to get them to agree to pay for the time spent on discovery. If they're a high priority lead, this cost can be deferred until they agree to start the project-- though you may have to guess at this point if you haven't already run the rubric. 7.
When the meeting is finished, write an email to the client summarizing what you went over in the meeting, and what the next steps are. Trigger the CI job here to migrate the meeting recording to google drive. Add an update with the link to the video (received via email after migration) and a summary of the discussion, and update the prioritization for the lead in the CRM. Also, set the due date on the lead to a week in the future (or other time as appropriate) to get a reminder to follow-up.
If you haven't already, be sure to add a mail archive link to the email thread with the client into an update as well.
Occasionally, a lead will come in asking for a single feature change to the platform. The feature is apparently small and the person or team is not looking for an extended engagement.
In cases like these, the client can be offered two choices:
- Run a discovery of up to five hours of billable time to create a blueprint of how long the feature will take and a final estimate.
- Have them agree to up to X hours of development (no fewer than 10) to see how far we can get on the feature. Deliver what we can if we don't complete it in that time.
Option 1 is unlikely to be chosen for these cases. Smaller features might take just as long to do a standard discovery as it would be to build them. Option 2 should be a ballpark estimate. Increase this estimate if you foresee any issues.
In cases like these, we do not assign a new client owner, but instead make this a one-off task assignment.
Request for Proposal (RFP) and Tender Projects¶
While most of our clients approach us to ask for quotes, a subset of companies we sell to publish a 'Request for Proposal' (private companies) or a 'Tender' (public ones) which are a general call for bids from vendors.
Tenders and RFPs are unique in that they require upfront investments from our team in order to submit our bids. In these cases we are unable to bill out the discovery time if we are not chosen. Sometimes, we cannot bill out even if we are chosen. To that end, we have some rules for engaging requests for proposals.
- We do not respond to RFPs and tenders for any group which does not score into the High Priority category of our lead prioritization rubric. All other organizations must go through the normal discovery process, or we will decline to work with them.
- If a lead does score into the high priority category, we will require payment for the discovery work upon acceptance of the terms.
- ...With one narrow exception. If the legal dictates of a government client's tender process prevent us from billing for discovery work, we will not bill for it. This will need close assessment from the Business Development Specialist to verify that the risk of sinking time into the tender is worth the cost. Private and nonprofit entities, as categories, will not be allowed to forgo discovery charges after acceptance.
All proposals should capture the full breadth of the discovery process costs. Meetings, discovery work, management overhead-- all of these need to be factored into the final price. The discovery process gives us a good view of what these costs will be.
If a project is fixed-price (that is, not to be long-term or iteratively developed), the proposal should contain the full estimated hours of the work, including time spent on discovery if it has not already been billed. Including the estimates sheet from the discovery process is recommended. You should always send the main discovery document.
If it is to be iteratively developed, the proposal should include the expected monthly development hours in one of the time banks at the bottom of the proposal template, rather than a lump sum. The proposal should be accompanied by the estimates spreadsheet, and the main discovery document, as always. Depending on the size and length of the engagement, a supplementary sheet showing year-by-year budget needs may also be necessary-- in most cases a client will ask for this if required.
Additionally, always send a link to this article to clients who will be engaging in iterative development with us, and make it clear that as we learn more about the project, the actual costs, features, and other work, are likely to change. Emphasize that estimates are based on what we know at this time only.
In some cases, you may wish to send an executive summary of OpenCraft and our work. These can be created in Proposify. Here is an example executive summary.
Transparency in Pricing¶
Including the estimates spreadsheet is important to make pricing transparent. While it is possible to 'roll' discovery and management hours into individual development tasks to pad them for required overhead, this makes a full understanding of how resources are to be spent difficult. It also requires a lot of manual work from the proposal writer to 'make everything fit.' It's better to dispense with this and lay out the costs out as transparently as possible.