How to write a clear request scope that can be priced
A clear request lets a provider price without guessing: a specific specialty, a property type and size, answers to the specialty's questions, and a start date and term. This guide walks through each step as Thibrh's request wizard asks for it.
Who this guide is for
An owner, association, property manager or facility manager who wants to ask for proposals.
Why a vague request holds up proposals
A request such as “I need periodic preventive maintenance for a residential building” is not enough to price, because the provider does not know the number of units, the systems involved or how often visits should occur. The provider either replies with questions or prices on assumptions that differ from one provider to the next, which makes comparison hard. That is why a request on Thibrh is published only with a service type from the family's specialties and answers to its mandatory questions, from a single schema that governs the wizard, the assistant, the server and the mobile app together.
The steps, in order
First choose the specialty precisely, since it determines your questions and the service family; for example, preventive maintenance belongs to facility management, not to maintenance and fit-out. Second, state the property type and its size, by number of units or by area depending on the specialty. Third, answer the specialty's questions, which number between three and five, most of them a single click. Fourth, set the start date and whether the service is one-off or recurring under a contract, and the contract length if recurring. Fifth, if you choose “Other”, write what you mean in a short text, since it is not accepted on its own.
What to add in your own words and what to avoid
Use the additional details for what is specific to your site: access hours available, building restrictions, earlier faults, and the reports you expect. Do not write suggested prices that would limit proposals, since the questions carry no price figures at all. Avoid writing an identity number, phone number, email, detailed address or individuals' names in the description; what is needed is the kind and size of the need, not the identity of the parties.
A final test before publishing
Read your request as a provider who does not know you: do you know what to price, how much, how often and when? Could two providers understand the request in different ways? If so, add what is missing. If you represent an association, say so; the representative capacity is chosen in the request but does not prove representation, and proof of capacity and the association's decisions are on Mullak.
Key points
- The specialty is mandatory and determines the request's questions.
- Property type, size, start date and term are set before publishing.
- Each specialty has three to five mandatory questions.
- “Other” requires a short text.
- Do not write data that identifies individuals in the description.