Question and scope
This review asks how consistent virtual assistant providers are in the response-time promises they publish, and how a buyer can compare them fairly. The unit is a public or contractual promise about acknowledgement or resolution. The scope includes websites, proposals, service agreements, and statements made during sales calls when they are confirmed in writing. The review does not rank providers or assume that a public claim is accurate.
A promise can be consistent in wording and inconsistent in meaning. One provider may start the clock at delivery, another at first read, and a third during published business hours only. A buyer who compares the numbers without the definitions will make a false comparison. The review therefore treats the definition as part of the promise.
The review also separates a promise from a target. A target may be an internal goal without a remedy, while a promise creates an expectation the buyer can enforce. The source document and the remedy determine which one the buyer actually has. That distinction matters more than the number in the sales deck.
The comparison should record the buyer's own request mix before it looks at provider promises. A buyer who sends mostly low-volume, high-complexity work needs a different promise from one who sends password resets. Count the request types and the arrival pattern first. The promise only matters against the work it will actually govern.
The comparison should state its own limits before it states a conclusion. Public terms change, sales claims drift, and a small sample cannot represent a whole market. Use the table to structure questions, not to declare a winner. A cautious comparison is more useful than a confident ranking built on mismatched definitions.
What counts as a promise
A promise is a statement that a request will receive a response within a stated period, or that a category of work will be completed within a stated period. Marketing language such as fast or dedicated is not a promise unless it carries a measurable commitment. A service-level agreement with exclusions is still a promise, but the exclusions must be read. Record the exact wording and the source date.
Separate acknowledgement promises from resolution promises. An acknowledgement can be automated, while a resolution depends on the task, the access, and the reviewer. A provider that promises both is making two different commitments. The comparison should keep them separate rather than collapsing them into one number.
Record whether the promise applies to the buyer's dedicated assistant or to a general support queue. A dedicated assistant may answer within minutes during the shift, while a queue may acknowledge quickly and resolve slowly. The staffing model changes the meaning of the number. Put the model beside the promise.
Collecting public and contract terms
Collect the current website page, the proposal, and the contract for each provider, and save a dated copy. Note the URL or document section for each promise. If a salesperson states a different number, ask for it in writing and treat the written version as the record. Do not rely on a memory of a call.
Record the provider's coverage window, time zone, holiday rule, and any exclusions. These details determine whether two promises are comparable. A promise of four hours during a ten-hour window is not the same as a promise of four hours around the clock. The collection template should force these fields.
Record the document date and whether the provider can change the term without notice. A promise in a proposal may not survive the contract, and a website promise may change without a version history. Keep the dated copy and the contract clause together. The comparison should show which document governs.
Ask the provider to show the report it uses to measure the promise. A dashboard screenshot without a definition is not enough, and a sample report with dates is better. If the provider cannot produce one, treat the promise as a target rather than a measured commitment. The evidence request is a normal part of procurement.
Normalizing clocks and coverage
Convert every promise to a common unit, such as hours of covered time, and state the assumed coverage window. If a provider does not publish a window, mark the promise as undefined rather than guessing. Do the same for holidays and weekends. The normalized value is only as good as the stated assumption.
Compare promises within the same request category, such as password resets or report changes. A general response promise may not apply to the work the buyer actually sends. Ask each provider to confirm which categories the promise covers. Record the answer beside the promise.
Show the normalization formula in the table so a reader can challenge the assumption. A comparison that hides its conversion looks objective while making an invisible choice. If two providers cannot be converted on the same basis, mark them as not comparable. That is a more honest result than a false ranking.
Compare the promise with the provider's published holiday calendar and its staffing location. A promise that assumes coverage on a client holiday may fail when the provider's team is off. The calendar is part of the service definition, not an administrative detail. Record the mismatch before signing.
Comparing like with like
Build a table with the promise, the clock start, the coverage, the category, and the evidence source. Sort by the normalized value only after the other fields are complete. Look for promises that are unusually short and check what they exclude. A short promise with broad exclusions may be weaker than a longer promise with clear coverage.
FTC guidance on advertising requires claims to be truthful, not misleading, and substantiated. A response-time claim is an advertising claim when it is used to win business. That does not prove a provider is wrong, but it gives the buyer a reason to ask for the basis. Request the measurement method behind the promise.
Limits of public claims
Public claims are written for buyers, not for auditors. They may omit the measurement period, the sample, or the consequences of a miss. A provider may also change the promise without changing the page date. Save the dated copy and check it again before signing.
A consistent set of promises across providers may reflect a common market convention rather than a common operating standard. The review can describe the convention but cannot infer the actual performance. Only the contract, the measurement method, and the buyer's own sample can test the promise. Treat the convention as a question to ask, not as evidence that the service works.
A provider that publishes no promise is not necessarily worse than one that publishes a weak promise. The absence is a different risk, not a score of zero. Record it as undefined and ask the provider to commit in writing. The comparison should not reward a vague claim simply because it sounds generous.
Distinguish a missed promise from a promise that was never measurable. A provider that says it responds quickly has not missed a measurable target because no target exists. The absence of a definition is a procurement gap, not a performance result. Report it as undefined rather than as a failure.
Questions buyers should ask
Ask when the clock starts, which hours count, which request categories are covered, and what happens when the promise is missed. Ask for one recent example of a measured response and the method used to measure it. Ask whether the promise is in the contract or only on the website. Record the answers in writing.
Compare the answers with the buyer's own volume and coverage needs. A promise that looks strong in a sales deck may be impossible during the buyer's busiest window. Put the agreed promise, the measurement method, and the remedy in the contract. The goal is a commitment both parties can test.
Put the final comparison in a form a non-specialist can read. One row per provider, one column for the promise, and one note for the definition and the evidence. Keep the detailed collection sheet as an appendix. A table that requires a glossary to understand will not be used in the buying decision.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role
