Giga connects support agents to a measurable improvement loop

Giga builds customer-support agents and the tools used to improve them. Its offer combines a builder called Agent Canvas, an AI assistant called Scout, and ways to act inside business systems. The useful buying question is whether that combination can improve a defined customer journey while preserving the service team’s control. A fluent answer, a successfully completed account action and a better business metric are different outcomes; a serious evaluation needs to connect them.

01 / ProductWhat Giga brings together

The current Giga platform presents an integrated cycle of building agents, examining conversations and improving support metrics. It is the customer-support company Giga AI, Inc., rather than the similarly named server-hardware business. The product is relevant when a team wants to own an ongoing automation programme, with a clear connection between what an agent does and what the support operation measures.

Agent Canvas starts from material such as policies, standard operating procedures and transcripts. Teams define agent behaviour, write support rules and run simulations. Those inputs play different roles. A policy describes what the company permits; a transcript shows how someone previously handled a case. A good implementation should not turn every historical workaround into an approved future action simply because it appeared in training material.

Scout adds a way to request changes in ordinary language. The practical advantage is reducing the distance between a service manager noticing a problem and a technical team receiving a concrete change proposal. It does not remove the need to decide who owns policy. If two departments disagree about a refund exception, asking an AI to reconcile their documents is not a substitute for resolving that disagreement.

02 / AudienceWhere an improvement-focused support platform fits

Giga makes the most sense for support operations with repeatable work, accessible systems and enough resolved cases to describe a meaningful baseline. A delivery business could have a large queue of late-order enquiries, but several different underlying outcomes: a status explanation, a replacement, a refund or contact with an operator. Treating them as one automation category would hide which work the agent actually performs well.

The service owner also needs a metric that reflects customer success. A shorter conversation can be helpful when the answer is complete; it can be harmful when the customer gives up. A lower escalation rate can mean better resolution or an agent that makes human help difficult to reach. The evaluation therefore needs a primary outcome and a small number of counterchecks, including repeated contacts and incorrect actions.

Our Decagon blueprint examines a comparable emphasis on developing service procedures and improving agents over time. The Intercom blueprint is useful when the buying decision also includes the human support inbox. Giga belongs in that comparison when the agent and its improvement process are the centre of the project, rather than a small extra feature on an existing messaging tool.

03 / WorkflowA proposed late-delivery workflow

Consider a proposed evaluation for customers asking about an overdue delivery. This is a design example, not a test we conducted in Giga. Begin with a limited set of order states and a policy defining which remedies are available in each. The agent should first establish the correct order, retrieve current delivery information and explain what is known. A stale tracking event should remain stale evidence, not become an invented arrival promise.

The next step depends on the customer’s request and the actual state. An explanation might finish a status enquiry. A request to cancel should trigger an eligibility check. A missing package may need investigation before compensation. Keep these branches distinct in the source procedure so a successful answer is not confused with successful completion of a remedy. The same distinction should appear in the evaluation record.

Giga’s Browser Agent describes acting inside web systems when an API is unavailable. That creates an option for a legacy dispatch console, but it changes what must be tested. A redesigned button, an expired login or a modal covering the page can affect execution. Verify that the agent confirms the final record state and can explain when an attempted operation did not complete.

For the first evaluation, use a controlled environment and representative historical cases. Giga’s pilot restrictions matter here: live customer-facing operation needs explicit permission in the order form. Include an already-refunded order, an unavailable dispatch system, two orders with similar references and a customer who changes their mind. These cases reveal whether the agent distinguishes an instruction from an irreversible transaction.

Scout describes analysing conversations, proposing fixes and comparing changes on a portion of traffic, with approval before shipping in its Slack workflow. Once a production agreement allows that stage, a sensible experiment might test a clearer explanation of tracking uncertainty. Keep remedy eligibility unchanged while measuring whether customers understand the answer. That makes the experiment interpretable: a wording change and a refund-policy change should not be evaluated as if they were the same intervention.

04 / PricingPrice the evaluation separately from production

The reviewed product pages direct buyers to a demonstration rather than a complete public numerical tariff. Giga’s Enterprise Pilot Terms, updated 26 August 2026 and consulted 28 September, give a more concrete starting point: evaluation access normally runs for eight weeks, fees come from the pilot order form, and a pilot does not automatically turn into a subscription. Expanded use requires a further agreement.

The same terms limit the pilot to evaluation unless the order form expressly authorises production, commercial or live customer-facing use. A product page describing a rapid rollout should not be read as contractual permission to put a pilot on real calls. Ask the proposal to distinguish test access, a permitted limited launch and the ongoing production service, with the relevant deliverables for each.

There is no useful cost comparison until the charging unit is clear. An order may produce several conversations across channels before it is resolved. For this proposed delivery workflow, ask how repeat contacts, transfers and unsuccessful system actions are treated. These are questions for the agreement, not claims that Giga separately charges for every item. The internal business case should also include procedure maintenance and the remaining work handled by people.

05 / DistinctionsThe metric definition is part of the product decision

Scout’s emphasis on investigating the conversations behind a metric is a meaningful part of Giga’s positioning. A dashboard can show that resolution fell, while a useful investigation must establish which type of customer request changed and why. The resulting improvement might be better knowledge, a corrected policy branch or a repaired integration. Each requires a different owner and a different check before release.

For the delivery example, keep a short record of the intended outcome, the system evidence and the customer’s final state. An agent might correctly report that a refund was issued while the customer still needs help finding a replacement. Counting the whole interaction as resolved would flatten that distinction. The value of an improvement loop depends on the quality of the outcome definition as much as the sophistication of the analysis.

06 / QuestionsQuestions to settle with actual cases

The public materials do not establish Giga’s accuracy, latency or financial return for your queue. We did not independently test those outcomes. Ask to see how an operator traces one answer to the policy and business-system result that supported it, then how the same case becomes a test after a failure. A reassuring aggregate result is less useful if the team cannot inspect the cases underneath it.

Browser execution deserves its own acceptance criteria. Identify which credentials and permissions the agent uses, how customer identity is established and what happens when the page reports an ambiguous result. Also establish how an authorised person stops an experiment or reverses a procedure change. These questions are especially consequential when the service can issue compensation or alter an order, because conversational quality cannot verify transaction correctness.

07 / DecisionChoose a narrow journey with a measurable end state

Giga is worth evaluating when the service team wants to develop and improve an agent as part of normal operations. Start with a journey whose successful completion can be checked outside the conversation. Agree on the pilot’s permitted environment, preserve a route to human help and make one improvement at a time. That creates evidence for a broader rollout without borrowing confidence from a polished demonstration.