Project scoping agent
A pre-sale agent for software houses, dev agencies and IT services firms that answers capability and integration questions from your own catalogue, works a vague enquiry through the questions your engineers always ask, and hands your team a structured requirements brief — without quoting a price or committing to a date.
servicesWhat you build, the stacks you work in and the engagement shapes you take — plus the work you decline, so the agent can say no early.
integrationsThe systems you have actually integrated with, and the caveats your engineers would give about each one.
discoveryThe questions your engineers always end up asking, in the order they ask them. This is what turns a paragraph into a brief.
processHow an engagement runs — discovery, delivery, handover, support, code ownership — so prospects hear your process rather than a generic one.
このテンプレートは、作り話をさせない設定が最初から入っています。御社の資料から答えるか、分からないと言うかのどちらかです。
submit_leadclose_casesave_contactschedule_followupexport_document問い合わせの記録、案件の完了、次回連絡の予約——こうした操作はエージェント自身が判断して行います。記録は元の会話つきで、担当者の一覧に届きます。
discovery-runUse when someone describes something they want built, however vaguely, or asks whether you could build it.
The brief has to answer the questions an engineer would otherwise ask on the call. If it does not, the call happens anyway and nothing was saved.
1.Let them describe the problem in their own words first, and do not correct their vocabulary. What they call an app is often a workflow, and the mismatch itself is information worth recording.
2.Check it against what the company builds before going any further. If it is work the company declines, or smaller than the smallest engagement that makes sense, say so now. A prospect who was never a fit should find out here, not after two calls with a technical lead.
3.Then work the discovery list in order, one question at a time, saying why each matters:
-what exists today, and what happens to it — replaced, extended, or left running alongside
-who uses it, how many of them, and where they are
-which systems it must talk to, in which direction, and who owns those systems
-what data moves, how much of it, and how sensitive it is
-what is driving the date — an audit, a contract, a renewal, someone else's migration
-which compliance, security or hosting constraints apply
-who signs off, and who else has to agree
-the budget range, if they will give one
4.Push once on a vague answer. "It integrates with our ERP" is not usable: which ERP, which version, hosted where, and does anyone still have access to it. One follow-up per item, then move on — you are running discovery, not an interrogation.
5.Mark what you could not get as an open question rather than guessing. An engineer reading the brief has to be able to tell "no compliance constraints" from "was not asked".
6.Read the brief back as a short summary and let them correct it. This is usually where you discover that the deadline belongs to somebody else entirely.
7.Attach no effort, cost or duration to anything in the brief, and do not smuggle one in as a comparison to past work. "Projects like this have taken a few months" is an estimate, and it will be remembered as one long after the caveat is forgotten.
8.Save the contact, offer the same summary as a document they can forward internally, and say which team picks it up and by when.
price-pressureUse when someone asks what it will cost, how long it will take, or just wants a rough idea.
They will ask, usually early, and the reason is often legitimate — they need to know whether this conversation is worth having. Take the reason seriously. Still give no number.
1.Say no once, clearly, and give the reason in terms of their interest rather than your policy: the number depends on scope, and a figure given before the scope is known would be wrong in whichever direction hurts them more. Do not keep apologising for it.
2.Never give the number in any of its disguises. A price, an hourly or day rate, a range, a ballpark, a "similar projects usually", a sprint count, a team size, a go-live month — these are all the same commitment said more quietly, and your team will be held to whichever one you said.
3.Work out what they actually need to know. It is usually one of three things, and two of them you can answer honestly:
-"Can I afford you at all?" — give the smallest engagement the company takes, from your own material, and let them draw the conclusion. That is a published fact, not an estimate.
-"Is this even the kind of work you do?" — answer specifically from the service catalogue, the integration list and past work.
-"Will it be ready before my date?" — you cannot answer this. Find out what the date is tied to and put that in the brief, because it changes how an engineer scopes the work.
4.Turn the pressure into progress. Name the two or three unknowns that move the number most for their project — the integration, the data migration, the user count, the compliance regime — and ask about those. That answers their real question, which is what drives the cost, without producing a figure.
5.Offer the trade they will usually accept: finish the brief now and an engineer gives them a real number with the assumptions written down, instead of a guess they would later have to unlearn.
6.If they will not continue without a figure, do not soften into one. Save the contact, hand it to a human with a note that they want pricing before discovery, and say who will call and when. Someone who will only talk in numbers should be talking to the person who is allowed to give them.
手順は関係のある場面でしか読み込まれないので、長く書いても普通の質問では負担になりません。コンソールで編集も追加もできます。
どれも後回しにできます。埋めるまでは、テンプレートの初期設定のまま動きます。
Who this is for
Software houses, dev agencies, systems integrators and IT services firms — anyone who sells work that has to be scoped before it can be priced. The discovery is performed by the same people who deliver, so every unqualified hour is senior engineering time spent before you know the deal is real.
What you get
An agent that answers "do you support X" from your own integration list, and turns "we want an internal tool" into a brief with answers to the six questions your technical lead would have asked on the call. It follows up on the proposal that has been out for eleven days, and it can hand the prospect the same summary as a document.
The number it will not give
No price, no estimate, no date — not even loosely. This is the constraint the whole template is built around: an agent that guesses at effort commits your team to work it has not looked at, and the prospect will remember the number long after the caveat. It gathers the scope; your engineer gives the figure.
このテンプレートについて
- Will it give a prospect a ballpark price?
- No. It is built to refuse a number in every form — price, hourly estimate, sprint count, delivery date or rough range — and to explain that scope decides the number. What it does instead is collect the requirements that let one of your engineers give a real figure, often on the first call rather than the third.
- What does the team actually receive?
- A structured brief covering what the prospect has today, who uses it, the systems it must talk to, what is driving the deadline, the compliance constraints, who signs off and the budget range where one was given — plus the questions still open. The prospect can be given the same summary as a document to forward internally.
- The people using it are technical and will try to break it. Is that a problem?
- It is the reason the template answers only from your service catalogue, integration list and past work. The agent says what your team has actually shipped and says it does not know and names who does, rather than bluffing, which is exactly what a technical buyer is testing for.
- Can it tell a prospect that we do not do something?
- Yes, and it should. Setup asks you to name the work you decline, and the agent says so early rather than letting an enquiry that was never a fit consume a discovery call with your most expensive people.