Vora
Find the point where the result changed
Start with the deliverable the client accepted. For the hypothetical service, it was a saved appointment request awaiting staff confirmation. The agent could collect a preferred time, but it could not promise a confirmed booking.
Rescheduling changes that result. It also introduces a record that already exists and a possible cancellation or replacement. A prompt edit may be a small part of the implementation; the supporting process needs more work.
Describe the requested behavior in ordinary language, including what the caller will hear and what staff will find afterward. Compare it with the acceptance condition. The first-client guide shows how to define that condition before selling a service.
If the original scope is vague, reconstruct it with the client from the proposal, approved tests and handover. Resolve the ambiguity before assigning the request a fee. A list of product features does not establish which behavior the agency agreed to deliver.
Separate defects from new work
A broken agreed behavior is a defect to investigate. New actions or supported conditions can require a scope change. Routine information maintenance may already be included in the fee.
Use the actual agreement and acceptance evidence when making that distinction. The following examples assume a request-only appointment service with one language, one location and an agreed allowance for business-information updates.
| Client request | Initial classification to inspect | What determines the answer | Work to consider |
|---|---|---|---|
| Corrected phone number is missing | Potential defect | Accepted tests require the final corrected number | Diagnosis, repair and regression tests |
| Update opening hours | Routine maintenance or change | Existing information-update allowance | Approval, update and relevant checks |
| Confirm bookings during calls | New action | Original service only records requests | Calendar access, booking states and failure recovery |
| Add another language | Expanded conditions | Language coverage in the original scope | Approved content, pronunciation and evaluation cases |
| Add a second office | Expanded coverage | Location and routing boundaries | Knowledge separation, destination rules and support |
| Produce a new weekly report | Additional deliverable | Reporting terms in the agreement | Data definitions, preparation and recurring review |
These are inspection categories, not universal billing rules. An agreement may include a second location from the start. A missed requirement may be the agency's error. Keep the reasoning with the decision so a future support person can understand it.
Calculate the recurring effect
Suppose the monthly fee is $1,200 and listed delivery costs are $400. The remaining $800 is 66.7% of revenue before other overhead, tax and acquisition costs.
These figures are hypothetical. They use the same starting service as the service-cost guide, not an observed Vora client or a recommended margin.
Now assume the added workflow requires six more hours each month at an internal cost of $50 an hour, plus $100 in extra usage or tools. Listed delivery costs rise to $800. The contribution falls to $400, or 33.3% of the same fee.
The agency still collects $1,200. It has half the contribution after the listed delivery costs.
Estimate initial implementation separately. A change can take several hours to build and then add recurring reviews, exceptions and support. Absorbing a small implementation cost as a goodwill decision does not make the ongoing obligation disappear.
For an uncertain estimate, state a range and the reason for it. If you have not inspected the client's scheduling access or failure behavior, that uncertainty belongs in the change proposal. A precise price built on an unchecked dependency can be misleading.
Trace the request through the workflow
Review the changed inputs, decisions, actions and saved results. Ask which nearby behaviors share those components.
For rescheduling, a caller may have two bookings. They may ask to move only one. The target slot may disappear while the agent is waiting, or the change may save even though the response times out. Decide what staff must inspect and how the caller receives an honest status.
Your test work grows with those supported states. Include cases that still need to work from the original service. Post-call workflow testing describes checking the saved record separately from the spoken response.
NIST's AI Risk Management Framework Core calls for testing before deployment and regular evaluation in operation. For an agency change request, that supports budgeting for verification beyond the first successful demonstration.
Also check the operating guide, staff training and reporting. If staff previously confirmed every request manually, their responsibilities may change when the agent can edit bookings directly. Someone needs to approve that new process.
Make the change decision small enough to use
A one-page change record is enough for many bounded services. Record the requested behavior, business reason, affected systems, acceptance conditions, delivery estimate and recurring effect. Include the earliest delivery date and the person authorized to approve it.
The agency and client can choose to fund the addition, trade away another part of the service, defer it or decline it. If you absorb the work, record the amount and whether that decision applies to implementation only. Otherwise, the next person may treat it as a permanent part of the package.
The Project Management Institute's published scope change control paper describes assessing cost and schedule impacts, approving the change and updating the plan. You can apply that process without turning a small client request into a long administrative exercise.
For the appointment example, the approval needs to settle:
- Which existing bookings the agent may find and change.
- How the workflow identifies the right caller and record.
- When the caller can hear that the change is confirmed.
- Who receives unresolved or partially completed changes.
- Which controlled cases must pass before release.
- How the one-time fee, monthly fee or existing scope changes.
- How staff return to the previous process if the new behavior fails.
If the value of rescheduling remains uncertain, use a paid AI pilot instead of quietly making the original service larger.
Give knowledge changes an approval path
Scope can expand through information as well as actions. A client may add services, introduce a new policy or send a document that conflicts with the existing source.
Define who approves business information and where the approved version lives. Ask what behavior should change after an update. A revised opening time is different from a new eligibility policy that requires the agent to make decisions about callers.
Keep version and test records for relevant updates. If a change affects answers across several intents or languages, account for that review effort. Selling unlimited edits while assuming every edit is a harmless sentence correction leaves the service cost unresolved.
Inspect work that already slipped into the fee
Review the previous delivery period's tickets and time records. Mark defects, included maintenance, approved changes and additions with no recorded decision. Check whether those additions now appear in the operating guide or recurring report.
Bring the client a factual list. Describe what was added, what it takes to maintain and what commercial choice needs to be made. Avoid surprising them with retroactive charges for work you chose to do without approval.
For the next request, open the accepted scope beside the proposed behavior. Mark every new action, supported condition and staff obligation before agreeing on the delivery date.