Illustrative sample
An actionable starting point.
Northstar Service Co. · Fictional business
This fictional example shows the shape of a paid assessment. It is not customer evidence, a quote, or a promise of results.
Recommended first capability
Enquiry response and routing
Start with enquiries that arrive when the team is busy.
Rationale · based on assumptions
For this example, the owner reports that new enquiries wait in a shared inbox. A defined response and routing process is a focused first step that can be tested before expanding.
The business context
Northstar is an imagined service business with a small office team, a shared inbox, a website enquiry form, and a basic CRM. The assumed problem is delayed follow-up during busy periods. The first objective is a reliable handoff to a person who can help.
Evidence & assumptions
- Example input: an owner reports inconsistent response times. No customer interviews or system records were used for this sample.
- Assumptions: enquiries can be identified, approved response language is available, and a person can own each handoff.
- Missing information: actual enquiry volume, baseline response time, CRM permissions, consent requirements, and staff capacity.
- Confidence: provisional until intake and system evidence are reviewed.
What this needs
- A named owner for routing and exception review.
- Approved access to the chosen enquiry source and CRM.
- Clear qualification criteria, routing rules, and permitted reply language.
- Test scenarios, an escalation path, and a way to pause.
- Staff feedback during a limited pilot.
Priorities, with a reason
- 01
Enquiry response and routing Start here
Addresses the assumed bottleneck directly. Begin with a narrow enquiry source and review exceptions before broader use.
- 02
Approved-answer assistant Consider next
Useful if repeated questions slow the team down and approved information is ready. Validate that need first.
- 03
CRM logging and follow-up Revisit later
Review after the first handoff works reliably. It depends on clean records, clear ownership, and agreed contact rules.
Other capabilities are not recommended without evidence that they solve a relevant problem.
Example agent blueprint
If the pilot goes ahead, the blueprint sets out what the agent may do on its own, what it hands to a person, and what it must never do. This example is fictional; real permissions are agreed with the business owner.
| Action | Who decides |
|---|---|
| Read new website-form enquiries | Agent, automatically. |
| Send the approved acknowledgement | Agent, using approved wording, within agreed hours and contact rules. |
| Create the enquiry in the CRM and assign an owner | Agent, following agreed routing rules, then confirming the record saved. |
| Answer pricing, scheduling, or eligibility questions | A person. The agent hands off with the details gathered. |
| Make offers, delete records, or contact people who have not enquired | Never. |
Existing tools, used first
- Reuse: the current website form and shared inbox stay as they are.
- Configure: owner and assignment rules set up in the existing CRM.
- Connect: the agent links the form to the CRM. No new system of record.
- Build: only routing logic the CRM cannot already handle.
- Human: exceptions, judgement calls, and every customer commitment.
How we would know it worked
- Agreed test enquiries, including awkward and out-of-scope ones, run before launch.
- Each result is checked in the CRM itself. A message sent is not counted as a job done.
- A named person can pause the agent at any time. Enquiries then fall back to the shared inbox.
- The owner signs off on the results before the pilot goes wider.
Commercial approach
The assessment is a separate paid engagement. Implementation and ongoing operation are scoped afterward.
| Cost category | What is confirmed before commitment |
|---|---|
| Setup & implementation | One-time work: configuration, integrations, testing, and handover. Quoted after scope. |
| Recurring management | Monitoring, maintenance, and agreed improvements. Separate recurring fee. |
| Software subscriptions | Required provider plans and existing subscriptions. Pass-through costs identified separately. |
| Usage | Model, messaging, or other usage charges based on volume and the selected services. |
Potential benefit, with visible assumptions
Illustrative calculation only: if 40 enquiries per week each involve 5 minutes of repeatable handling, and a verified workflow removes 2 of those minutes, potential time released is 80 minutes per week. The team still handles exceptions and customer decisions.
These figures are fictional assumptions, not measured savings. Verify volume and handling time during the baseline; do not treat released time as revenue or guaranteed cost reduction.
How we would verify progress
- 1. Baseline
Measure current response times and manual effort for a representative period.
- 2. Pilot
Test a limited enquiry source against agreed scenarios and review exceptions.
- 3. Review
Compare results and decide whether to improve, expand, or stop.
- Median first response time
- From enquiry arrival to a useful first response.
- Qualified enquiries routed
- Correct handoffs against agreed criteria.
- Enquiries that become booked meetings
- Compared with the baseline period, not assumed in advance.
- Staff corrections
- Wrong replies, missed details, and routing exceptions.