Co dělat, když klient nahraje špatný soubor

Aktualizováno: · Autor: Radim Sekera

Zavoláte request_revision na tu konkrétní položku s poznámkou, co je špatně — z dashboardu nebo z agenta přes MCP/REST. BriefGate vyznačí jen tuhle jednu položku v portálu, pošle klientovi e-mail, a zbytek sběru podkladů jede dál; nemusíte posílat celý sběr znovu ani opravu řešit zvlášť přes e-mail.

Proč tohle potřebuje vlastní krok

Klient může odeslat soubor, který projde každou kontrolou, kterou BriefGate umí, a přesto je to špatný soubor. Položka typu file omezená na formats: ["pdf"] v klidu přijme PDF, které je ale nepodepsaný koncept místo podepsané smlouvy — formát sedí, obsah ne, a žádná kontrola formátu ani velikosti to nezachytí, protože BriefGate validuje jen to, co umí ověřit mechanicky (přípona, velikost, pixelové rozměry), a nemá způsob, jak přečíst význam dokumentu. Referenční dokumentace typů položek to říká přímo: „BriefGate does not infer constraints from file content or other heuristics" (BriefGate neodvozuje omezení z obsahu souboru ani jiných heuristik). Zachytit nesoulad v obsahu je lidský úsudek, který udělá ten, kdo odeslané podklady posuzuje — a jakmile ho uděláte, potřebujete způsob, jak klienta poslat zpátky opravit jen tu jednu položku, bez narušení zbytku sběru nebo vedlejší konverzace přes e-mail.

Volání request_revision

Z agenta přes MCP:

json
{
  "intake_id": "in_8f3kQmR2",
  "item_key": "signed_contract",
  "note": "Tohle je koncept bez vašeho podpisu — potřebuji podepsané PDF, které jste dostali zpátky z tiskárny, ne verzi, kterou jste poslali k revizi."
}
json
{
  "intake_id": "in_8f3kQmR2",
  "item_key": "signed_contract",
  "status": "needs_revision",
  "client_notified": true
}

Ekvivalent v REST je POST /v1/intakes/:id/revision se stejným item_key a note v těle požadavku; z dashboardu je to tlačítko přímo u položky, kam se poznámka napíše do textového pole místo JSON. Všechny tři cesty vedou ke stejné změně stavu a volání uspěje jen tehdy, když je položka zrovna submitted nebo approved — požádat o revizi položky, které se nikdo nedotkl, skončí 409 conflict, protože tam není co opravovat.

Co vidí klient, a kdy

Klient dostane e-mail s vysvětlením, že konkrétní položka potřebuje pozornost, a odejde ve chvíli, kdy zavoláte request_revision — nečeká se na klientův nejbližší naplánovaný termín upomínky jako u automatického rytmu, a nedrží ho ani noční klid, protože je to záměrná zpráva o konkrétní věci, ne obecné postrčení, které může počkat do rána. Prokliknutí ho zavede na stejný odkaz na portál jako vždy, kde se u vyznačené položky objeví banner s vaší poznámkou přesně tak, jak jste ji napsali:

„Tohle je koncept bez vašeho podpisu — potřebuji podepsané PDF, které jste dostali zpátky z tiskárny, ne verzi, kterou jste poslali k revizi."

Dotkne se to jen téhle jedné položky. Všechno ostatní, co už odeslal, zůstává přesně tak, jak bylo — schválené položky zůstávají schválené, ostatní čekající zůstávají čekající — a stav položky se vrátí na needs_revision, aby ji klient mohl nahrát znovu na stejném místě. Ve chvíli, kdy to udělá, se vrátí na submitted, znovu se spustí 72hodinové hodiny automatického schválení (nebo jiná hodnota, kterou jste nastavili v auto_approve_hours) a na webhooku se znovu spustí item.submitted, stejně jako při prvním odeslání.

Stojí za to znát jeden rozdíl, pokud zároveň pracujete s rozvrhem upomínek: oznámení o revizi se nepočítá do stropu max_reminders tak, jako naplánovaná upomínka nebo ruční send_chase. Upomínky, které dorazí v rozumnou hodinu ten strop rozebírá do detailu — ve zkratce tu platí, že žádost o opravu konkrétní položky neukrajuje z rozpočtu obecných postrčení, která má rytmus k dispozici, než se sběr zasekne.

Na tarifu Free tohle nejde

Žádost o revizi potřebuje funkci revisions, která na tarifu Free není dostupná — jak tlačítko v dashboardu, tak volání MCP/REST tam vrátí plan_required. Na Free zbývá jen napsat klientovi mimo BriefGate a počkat, až znovu odešle přes portál, nebo přejít na vyšší tarif. Náhradu nenabízí ani send_chase: ten pošle stejné obecné postrčení o všem, co ještě chybí, bez pole pro poznámku a bez možnosti vyznačit jednu konkrétní položku.

Jak tomu předejít

Žádost o revizi opraví špatný soubor až poté, co dorazí; tomu, aby většina špatných souborů vůbec nepřišla, zabraňuje už samotná definice položky. Dělají to tři věci:

json
{
  "key": "signed_contract",
  "label": "Podepsaná smlouva o projektu",
  "help": "Nahrajte podepsané PDF, které jste dostali zpátky z tiskárny — ne koncept, který jste poslali k revizi.",
  "type": "file",
  "required": true,
  "constraints": {
    "formats": ["pdf"],
    "max_bytes": 10485760
  }
}

Nic z tohoto request_revision nenahrazuje — klient si může i nejjasnější nápovědu přečíst špatně, nebo nahrát správný formát se špatným obsahem — ale zužuje množinu případů, které revizi vůbec potřebují. Obě věci se doplňují: omezení a nápověda řeší „na první pohled špatně", request_revision řeší „vypadá to dobře, a není".

Související

Související návody

Nejste vývojář? Podívejte se na stránku pro sběr podkladů nebo projděte všechny návody.