Guide
The context sheet, published in full
Every build starts with the same document. It is not a proposal and it is not a requirements spec. It is the set of facts a system needs in order to answer as your business rather than as a generic version of your industry, and it is the single largest determinant of whether the finished thing sounds like you. We are publishing it because it works whether or not we are the ones building, and because a business that fills it in is better off even if the project never happens.
Why this exists
Ask a system to answer a customer and it will answer as the average business in your sector, because that is all it has. The gap between that and a real answer is not intelligence, it is knowledge, and the knowledge lives in a handful of people's heads.
This sheet gets it out of their heads and onto a page. The same page is also the fastest onboarding document a new hire will ever get, which is the honest test of whether it is filled in properly.
Section 1: What the business actually is
Deceptively hard. Most owners answer with what they sell rather than what they do, and the two are different in ways that matter to whoever is asking.
- What you do, in a sentence a customer would use. Not your industry's word for it. The word the person typing into a search box would use.
- Who you serve, and who you do not. The second half is the useful half. Residential only, commercial only, no jobs under a certain scope, no new construction.
- Where you serve. Named places, plus the honest edge: how far out you will actually travel and when the answer changes.
- What you refuse. The work you turn down, and why. This is the fastest way to make a system stop offering things you do not do.
- What makes you different from the shop down the road. Answered with something checkable, not with an adjective.
Section 2: How the work actually happens
The operational reality, described the way it is rather than the way the website describes it. A system that has this can answer the questions buyers actually ask, which are almost all process questions.
- What happens between first contact and the work starting. Every step, including the ones that are somebody walking to the back to check.
- Who does what. Names and roles, so a handoff goes to the right person rather than to a shared inbox.
- What you need from the customer, and when. The documents, measurements, access or decisions that hold jobs up.
- What your real lead time looks like this month. Not the aspirational one.
- What goes wrong most often, and what you do about it. This is the section people skip and it is the one that makes a system useful under pressure.
Section 3: The questions you answer all day
Ask the person who answers the phone rather than the owner. They will give you twenty in about four minutes, and they will be different from the twenty the owner would guess.
For each one, record the answer as they would actually say it out loud, not as it would be written on a website. The spoken version is nearly always better.
- The questions themselves, in the customer's words.
- The real answer, in your words.
- Which ones have an answer that changes seasonally, and what it changes to.
- Which ones you are not willing to answer without a person involved.
Section 4: How you sound
Not adjectives. Mechanics. The specifics that make writing recognisably yours are almost all structural, and they are easy to record once someone points at them.
- Three real examples of your own writing that you are happy with. An email to a customer beats a page of your website, because the website was probably written by someone else.
- Words and phrases you use. Including the trade-specific ones and the ones you would never say.
- Words and phrases you refuse. Everyone has them. Solutions, journey, passionate, unlock.
- Whether you address people directly, use contractions, or open with a greeting. Small, and it is most of what tone is.
- Which language, and whether that changes by customer. In Québec this is a real operational answer, not a preference.
Section 5: The lines the system must not cross
The most important section and the one that takes the longest, because it is the only part that cannot be inferred from anything else. It is also the part a compliance officer will want to read.
- What a system may never say. Prices, availability guarantees, clinical or legal opinions, liability, anything requiring a licence.
- What must always reach a person, immediately. Complaints, safety issues, anything from a named account, anything it is not confident about.
- Who that person is, and what happens outside business hours.
- What must be recorded, and for how long. Both the operational answer and the regulatory one.
- What the system must say about being a system. Whether it identifies itself, and in what words.
Section 6: The systems it has to live with
Short, factual, and worth getting exactly right, because most of the effort in a build is here rather than in the model.
- Every system that holds customer information, and which one is the record when two disagree.
- Who administers each, and whether that is somebody in the building.
- What can be read from each, and what can be written back.
- What is still on paper or in one person's spreadsheet.
A worked example
Filled in for a fictional Laval plumbing company, at the level of detail we would actually accept. Compare each answer to what a competitor could write. That is the whole test.
| Field | A weak answer | An answer we would accept |
|---|---|---|
| What you do | Quality plumbing services | Emergency and repair plumbing for houses and duplexes. Not new construction, not commercial. |
| Who you do not serve | (left blank) | No new builds, no commercial kitchens, no jobs where we would be the third plumber on the same problem. |
| Where | Greater Montreal | Laval and Ile Bizard same day. North shore next day. We do not cross to the south shore. |
| Real lead time | Fast turnaround | Emergencies within four hours. Everything else is currently eight to eleven days, and that doubles in the first cold week of November. |
| Most common question | Customers ask about pricing | Is this an emergency or can it wait until morning. We answer it by asking whether the water is still running and whether they found the shutoff. |
| What goes wrong | (left blank) | We arrive and the access is blocked, or nobody knows where the shutoff is. Both are preventable with one question when the call comes in. |
| Never say | Be professional | Never quote a repair over the phone, never say a part is in stock without checking, never tell somebody it can wait until morning. |
| Always escalate | (left blank) | Anything with gas, anything with a smell, anything where somebody says the word flooding. Straight to Marc, any hour. |
How to actually fill it in
The version that works is not a form sent by email. It is a conversation that gets written down, because the useful answers are the ones people say out loud and would never type.
- Sit with the person who answers the phone for forty minutes. Record it, with their agreement. Do not send them the sheet in advance.
- Ask what people ask, then ask what they actually say back. Write the spoken answer.
- Ask what goes wrong. Wait through the pause. The second answer is the real one.
- Take the never-say and always-escalate lists to whoever owns the risk: the owner, the compliance officer, the licensed professional. They own that section, not you.
- Write it up as one document, not a spreadsheet. Two to four pages is normal and correct.
- Give it to somebody who does not work there and ask them to answer three customer questions from it. Everything they cannot answer is a gap.
- Date it, put one name on it, and diarise it for six months. A context sheet nobody owns is out of date within a season.
What it is worth on its own
Most businesses that fill this in find something before any system gets built. The lead time everybody quotes is not the real one. Two people give different answers to the same common question. The escalation rule everyone assumes exists has never been written down.
That is not a side effect, it is most of the value. A build makes an existing process faster. If the process is undefined, all a build does is make the inconsistency arrive quicker.