Sorting Known, Assumed and Requested Facts Before a Keyphone Quote

Why a keyphone quote needs a fact sort before anything else

A keyphone enquiry often starts as a short message: we need phones for a small office, please quote. That sentence contains almost nothing a supplier can work with, yet it feels complete to the person who wrote it. The gap between what the buyer believes they have said and what the supplier can actually act on is where most back-and-forth begins.

A useful habit before sending that enquiry is to sort your facts into three buckets. Known facts are things you can state with confidence and evidence: the number of desks, the rooms involved, the way calls are handled today. Assumed facts are things you believe but have not confirmed, such as whether the front desk shares one number or whether the current cabling will carry a new system. Requested facts are things you want the supplier to tell you, such as what a handset option includes or how after-hours calls are handled.

The sort matters because each bucket leads to a different next question. Known facts let the supplier size the conversation. Assumed facts need checking before they harden into a quote line. Requested facts belong in the reply, not in the brief. This guide uses one fictional example throughout: a small office in Sarawak asking about a keyphone system. The office, the staff and the numbers are invented for illustration only.

Eyonic Security Systems plans, supplies and installs CCTV systems for homes, offices, shops and industrial sites in Sarawak, and the same discipline of clarifying scope before quoting applies to how security work is scoped. The keyphone page is a separate product line, so treat this article as a thinking method rather than a description of that system.

The fictional brief: a small office with three open questions

Imagine a fictional office of about a dozen people in a shophouse unit. The manager writes: we need a keyphone system for the office, around twelve staff, front desk handles calls, please advise. Three questions sit underneath that message, and each one belongs in a different bucket.

First, how many desks need a handset. The manager may know this exactly, or may be counting people rather than positions. Someone who works mostly outside the office may not need a desk phone. A shared workstation may need one handset between two people. Until the count is confirmed desk by desk, it is an assumption dressed as a known fact.

Second, whether the front desk shares one number. This is often assumed rather than known. The manager may believe the front desk has its own line because that is how it has always felt, but the actual arrangement may be a main number answered at the desk, with other calls routed elsewhere. The difference changes what the supplier needs to ask about call handling.

Third, who answers after hours. This is usually a requested fact in disguise. The manager wants to know what happens when nobody is at the desk, but has not yet decided what the office wants. Does a call ring through to a mobile, go to a shared voicemail, or simply ring out? The answer is a business decision before it is a technical one.

Writing these three questions down and labelling them is the whole exercise. It takes a few minutes and saves a round of clarification later.

Known facts: what you can state without checking

A known fact is something the buyer can state and defend. In the fictional office, known facts might include the address of the unit, the number of rooms where a handset is wanted, the fact that the front desk is staffed during office hours, and the fact that the office already has some cabling in the walls. Each of these can be written in one line and does not need a supplier to confirm it.

The discipline is to keep known facts narrow. It is tempting to write twelve staff need twelve phones, but that is a conclusion, not a fact. The fact is that twelve people work in the office. How many handsets that implies is a decision that follows from the desk count.

Known facts also include constraints the buyer controls. If the office cannot run new cabling through a particular wall, that is known. If the landlord requires approval for any drilling, that is known. These constraints shape what the supplier can propose, and stating them early prevents a proposal that cannot be installed.

A useful test: could you show a colleague the evidence for this fact in under a minute? If yes, it is known. If you would have to say I think so, it is an assumption.

Assumed facts: the ones that quietly shape the quote

Assumed facts are the most dangerous bucket because they feel like knowledge. In the fictional office, the manager assumes the front desk shares one number with the main office line. That assumption may come from years of habit rather than from looking at how calls actually arrive.

Another common assumption is that the existing cabling will support a new keyphone system. The manager has seen cables in the wall and assumes they are suitable. Whether they are depends on what kind of cable was installed and where it runs, which is a question for a site visit rather than a guess.

A third assumption is about growth. The manager assumes the office will stay at twelve people for the next few years. That may be true, but if a second team is planned, the assumption changes what the supplier should discuss about capacity.

The handling of an assumed fact is not to delete it. It is to mark it clearly and turn it into a question. Instead of writing the front desk shares one number, write: assumed the front desk shares one number, please confirm what you need to check this. That single change tells the supplier where to focus the conversation.

Eyonic's approach to smart lock door access follows a similar pattern: the review notes that smart locks work best when the door condition, user roles and backup method are reviewed before installation, and that for business use the choice between a standalone smart lock and an access-control panel is checked first. The lesson transfers: assumptions about the physical setup are worth surfacing before a proposal is built.

Requested facts: what you are asking the supplier to answer

Requested facts are the questions the buyer wants answered. They are not weaknesses in the brief; they are the reason the brief exists. In the fictional office, the manager wants to know how after-hours calls are typically handled, what happens when the front desk is away from the desk, and whether a handset is needed in every room or only in some.

Keeping requested facts separate stops them from being mistaken for requirements. If the manager writes we need after-hours calls to go to mobile, that is a requirement, and the supplier will quote to it. If the manager writes we want to understand after-hours options, that is a request for information, and the supplier can explain the choices before anything is fixed.

The distinction matters because a quote built on an unexamined requirement can be accurate and still wrong. The supplier answers the question that was asked, the buyer discovers the answer does not match how the office actually works, and the quote is revised. Separating requests from requirements gives the buyer room to decide after hearing the options.

A practical format is a short list headed Questions for the supplier, with each item written as a question rather than a statement. That list becomes the agenda for the first call.

How the labels change the next question

The value of the sort shows up in what you ask next. Take the three questions from the fictional brief and watch each label redirect the conversation.

How many desks need a handset. If this is known, the next question is about placement: which desks, which rooms, and whether any shared positions need a handset. If it is assumed, the next question is internal: walk the floor and count positions rather than people. The supplier does not need to be involved until the count is settled.

Whether the front desk shares one number. If this is known, the next question is about call handling at the desk. If it is assumed, the next question is to the current provider or to whoever manages the line: how do calls arrive today? That answer may change the brief before it is sent.

Who answers after hours. If this is requested, the next question goes to the supplier: what options exist, and what does each one require from the office? If the office has already decided, it becomes a known requirement and the supplier quotes to it. The label tells you who to ask.

This is the practical payoff. A brief sorted into three buckets produces a shorter first call, fewer revised quotes, and a clearer record of what was decided and why.

A short checklist you can apply to any security quote

The same three-bucket sort works beyond keyphones. Before sending any security enquiry, run the brief through a short checklist. These timings are author heuristics, not researched benchmarks.

First, list every statement in the brief and mark it K, A or R. Aim to finish this in about ten minutes for a small office. Second, for every A, write the question that would confirm or correct it, and decide whether you can answer it yourself or need the supplier. Third, for every R, rewrite it as a question rather than a requirement unless the office has already decided. Fourth, check that no known fact is actually a conclusion, such as twelve staff means twelve phones.

For security work specifically, the same logic applies to camera placement and site survey questions. A buyer who assumes a camera will cover a doorway without checking the angle is making the same kind of assumption as the keyphone buyer who assumes the front desk shares one number. Eyonic lists site survey and camera placement among its service areas, and both are the kind of question best raised before a proposal rather than after installation. The same applies to NVR setup and remote viewing: what the buyer wants to see remotely is a requirement worth stating clearly, while how it is configured is a question for the supplier.

A sorted brief is not a longer brief. It is a brief where each line has a job.

What to bring when you ask for a keyphone quote

When you are ready to discuss a keyphone system, bring the sorted brief. The known facts set the scope, the assumptions become the checks, and the requested facts become the agenda. That is a more useful starting point than a one-line request, and it keeps the conversation on what the office actually needs.