شفافیت در کسبوکار یعنی مشتری اطلاعات کافی، روشن و درست برای تصمیم و اقدام داشته باشد؛ نه اینکه سازمان هر سند داخلی را منتشر کند. نمایش انبوه متن حقوقی، قیمت بدون هزینه نهایی یا عذرخواهی بدون Remedy میتواند ظاهراً «شفاف» باشد و همچنان مشتری را گمراه یا بیدفاع بگذارد.
این راهنما شفافیت را از شعار به Operating model تبدیل میکند: Claimها ثبت میشوند، Disclosure owner و Freshness SLA دارند، تغییر و رخداد با Notice مشخص اعلام میشود و Trust repair فقط با حرف پایان نمییابد. هدف، اعتماد کالیبره است؛ مشتری بداند چه چیزی معلوم، نامعلوم، محدود، تغییرپذیر یا جبرانشدنی است.
خلاصه اجرایی
- Transparency را با Disclosure، Clarity و Accuracy بسنجید؛ نه حجم اطلاعات.
- Relevance، Timing، Findability، Verifiability و Actionability را به آن اضافه کنید.
- برای Price، Product، Availability، Terms، Data، Change و Incident حداقل افشا تعریف کنید.
- هر Claim باید Owner، Evidence، Scope، Expiry و Correction route داشته باشد.
- Known، Unknown، Impact، Action و Next update را در Notice رخداد جدا کنید.
- Privacy، Security، Safety، Trade secret و ادعای تأییدنشده مرز افشا هستند.
- Trust repair به Protection، Acknowledgment، Remedy و System fix نیاز دارد.
- Loyalty را نتیجه قطعی Transparency فرض نکنید؛ رفتار و تجربه را جدا بسنجید.
مرز این صفحه با موضوعات نزدیک
| پرسش | مرجع |
|---|---|
| چه اطلاعاتی، چه زمانی و با چه کیفیتی افشا شود؟ | همین صفحه |
| بازخورد مشتری چگونه دریافت و Close شود؟ | مدیریت Voice of Customer در ۶۱۳ |
| Service recovery و وفاداری چگونه سنجیده شود؟ | قدردانی و بازیابی خدمت در ۴۵۸ |
| ادعای برند چگونه به Evidence وصل شود؟ | Claim–Evidence و شهرت در ۳۸۰ |
| کیفیت در بحران چگونه کنترل شود؟ | Crisis quality در ۵۹۳ |
شفافیت چیست و چه چیزی نیست؟
| Transparency مؤثر | Transparency نمایشی |
|---|---|
| اطلاعات مرتبط پیش از تصمیم | صد صفحه Terms پس از پرداخت |
| قیمت نهایی و فرضها | عدد اولیه بدون کارمزد/ارسال |
| محدودیت محصول کنار Claim | Disclaimer پنهان در Footer |
| Known/Unknown/Next update | «در حال بررسی است» بدون زمان |
| Correction قابلردیابی | ویرایش بیصدا |
| Evidence و Scope | عدد بزرگ بدون تعریف/بازه |
| Action برای مشتری | اطلاعرسانی بدون راه جبران |
سه بُعد پایه و پنج بُعد اجرایی
| بُعد | سؤال کنترل | Red flag |
|---|---|---|
| Disclosure | اطلاعات مرتبط واقعاً ارائه شده؟ | حذف محدودیت مادی |
| Clarity | مخاطب هدف میفهمد؟ | زبان حقوقی/فنی بیتوضیح |
| Accuracy | با Evidence و وضعیت فعلی منطبق است؟ | ادعای منقضی |
| Timeliness | پیش از تصمیم/زیان رسیده؟ | اعلام پس از وقوع هزینه |
| Findability | در Journey قابل یافتن است؟ | سه Click و Footer |
| Verifiability | Scope، منبع و تاریخ دارد؟ | «بهترین» بدون معیار |
| Actionability | مشتری میداند چه کند؟ | Notice بدون Route |
| Consistency | Sales، Site و Support یک نسخه دارند؟ | سه پاسخ متفاوت |
اعتماد کالیبره، نه اعتماد حداکثری
Transparency همیشه خبر خوب نشان نمیدهد. ممکن است Backlog، محدودیت، خطا یا قیمت بالاتر را آشکار کند. این افشا شاید خرید کوتاهمدت را کم کند، اما تصمیم را آگاهانهتر میکند. معیار اخلاقی و عملی این نیست که هر Notice اعتماد را زیاد کند؛ باید فاصله تصور مشتری با واقعیت را کم کند.
| سازه | تعریف عملی | معادل نیست با |
|---|---|---|
| Transparency | کیفیت اطلاعات تصمیم | افشای همهچیز |
| Trustworthiness | ادراک Ability/Integrity/Benevolence | محبوبیت برند |
| Trust | پذیرش آسیبپذیری در Context | اطمینان مطلق |
| Satisfaction | ارزیابی تجربه مشخص | خرید مجدد |
| Loyalty | نگرش/رفتار در Horizon تعریفشده | ماندن از اجبار یا Switching cost |
پژوهش چه مرزی میگذارد؟
| منبع | کاربرد | حد تفسیر |
|---|---|---|
| Schnackenberg et al. 2021 | Disclosure، Clarity و Accuracy بهعنوان ساختار Transparency | ادراک اطلاعات؛ Checklist قانونی نیست |
| Schnackenberg & Tomlinson 2016 | پیوند نظری Transparency و Trust ذینفع | چارچوب مفهومی، نه تضمین Loyalty |
| Mohan et al. 2020 | شش مطالعه Cost transparency و Trust/Purchase interest | Context-specific؛ افشای همه هزینهها نسخه عمومی نیست |
| Xie & Peng 2009 | Informational، affective و functional repair | آزمایش سناریومحور و Publicity منفی |
| Gillespie & Dietz 2009 | Trust repair سیستمی و چندمرحلهای | چارچوب نظری؛ Context مشتری را جدا بسنجید |
Materiality Gate: چه چیزی باید اعلام شود؟
«مهم بودن برای سازمان» کافی نیست. اطلاعاتی Material است که میتواند تصمیم، هزینه، ایمنی، حریم خصوصی، امکان استفاده، حق انصراف یا زمان مشتری را بهطور معنادار تغییر دهد.
| سؤال | اگر بله | نمونه |
|---|---|---|
| تصمیم خرید/تمدید را تغییر میدهد؟ | قبل تصمیم افشا | قیمت نهایی/محدودیت |
| خطر مالی/سلامت/داده میسازد؟ | Notice فوری + Action | نشت/فراخوان/هزینه |
| وعده قبلی تغییر کرده؟ | Change notice + Choice | SLA/Feature/Delivery |
| عدم اعلام، حق جبران را کم میکند؟ | Route و Deadline | مرجوعی/گارانتی |
| ادعای عمومی بدون Evidence است؟ | Hold/qualify/correct | پایداری/بهترین/امن |
| افشا به فرد ثالث آسیب میزند؟ | Redact/aggregate/withhold | PII/امنیت/تحقیق |
Customer Disclosure Contract
| فیلد | نمونه |
|---|---|
| disclosure_id | DSC-2026-041 |
| Decision/Audience | خرید اشتراک برای مدیر مالی |
| Statement | قیمت، مالیات، ارز، تمدید |
| Evidence source | Pricing config/Policy/Contract |
| Owner/Approver | Product/Finance/Legal |
| Trigger | checkout/change/incident |
| Channel/Placement | کنار CTA + email + account |
| Freshness SLA | sync فوری؛ audit هفتگی |
| Action/Choice | accept/decline/cancel/contact |
| Correction | owner، version، customer notice |
Disclosure Map در سفر مشتری
| Moment | حداقل اطلاعات | Trigger update |
|---|---|---|
| Discovery | Claim، Scope، Eligibility، Limit | campaign/change |
| Comparison | Feature، exclusion، evidence date | release/pricing |
| Checkout/Contract | total price، term، renewal، refund | quote/payment |
| Onboarding | delivery، dependency، support | start/delay |
| Use | status، limits، data behavior | degradation/policy |
| Change | what/why/impact/date/choice | approved change |
| Incident | known/unknown/impact/action/update | threshold crossed |
| Exit/Recovery | refund، export، deletion، remedy | cancel/complaint |
Claim Register
هر ادعای عمومی را یک Asset قابلنسخهبندی ببینید. صفحه برند، Script فروش، Proposal، FAQ و پاسخ Support نباید Claimهای متناقض داشته باشند.
| فیلد | کنترل |
|---|---|
| Claim text | عبارت دقیق، نه خلاصه مبهم |
| Scope | محصول/پلن/شهر/بازه/شرط |
| Evidence | منبع، روش، Sample، تاریخ |
| Owner | پاسخگوی صحت و Update |
| Placement | همه Channelها و نسخهها |
| Expiry/review | تاریخ بازبینی یا Event trigger |
| Qualification | Limit/exception کنار Claim |
| Correction log | چه چیز، چرا، چه کسانی مطلع شدند |
شفافیت قیمت برای بازار ایران
در محیطی با تغییر قیمت، شفافیت یعنی واحد پول، اعتبار Quote، مالیات، ارسال، نصب، کارمزد، نرخ تمدید و شرط تعدیل پیش از تعهد روشن باشد. نمایش عدد قدیمی و تغییر آن در تماس فروش، Information debt است؛ حتی اگر قیمت جدید موجه باشد.
| فیلد قیمت | نمونه کنترل |
|---|---|
| Unit | ریال/تومان، ماه/سال، نفر/مصرف |
| Included/excluded | مالیات، ارسال، نصب، Support |
| Validity | تاریخ/ساعت و مدت Quote |
| Renewal | نرخ/قاعده/زمان Notice |
| Adjustment | Index/trigger/cap/choice |
| Refund/cancel | شرط، مبلغ، زمان و Route |
Cost transparency در بعضی Contextها میتواند Trust و Purchase interest را بالا ببرد، اما الزام عمومی به افشای Margin نیست. اول نیاز تصمیم مشتری و Risk گمراهی را مشخص کنید.
شفافیت محصول و محدودیت
- Compatibility، prerequisite و محیط پشتیبانیشده.
- Performance benchmark با Dataset، بازه و شرط.
- Availability واقعی، Backorder و Lead time.
- Feature plan را از Feature موجود جدا کنید.
- AI/automation involvement و نیاز به Human review، وقتی برای تصمیم مادی است.
- Known limitation کنار Benefit؛ نه در لینک دور.
- Testimonial با Context و عدم تعمیم نتیجه فردی.
شفافیت Terms، گارانتی و مرجوعی
Policy در Footer کافی نیست. شرطی که میتواند تصمیم را تغییر دهد باید در Moment مربوط دیده شود: بازه مرجوعی، استثنا، وضعیت بستهبندی، هزینه ارسال، زمان بازپرداخت، Coverage گارانتی و مدرک لازم.
| آزمون | سؤال |
|---|---|
| Proximity | کنار خرید/انتخاب است؟ |
| Plain language | کاربر هدف میتواند بازگو کند؟ |
| Symmetry | Benefit و Restriction هموزناند؟ |
| Friction | Cancel/refund از خرید سختتر نیست؟ |
| Evidence | رسید و Case status قابلپیگیری است؟ |
شفافیت داده مشتری
عبارت «برای بهبود تجربه» Purpose کافی نیست. در لحظه جمعآوری بگویید چه دادهای، برای چه Purpose، با چه Recipient، تا چه مدت، با چه Choice و چگونه قابل دسترسی/اصلاح/حذف است. بررسی الزامات حقوقی جاری و قراردادهای محلی باید جدا انجام شود.
| فیلد Notice | پرسش |
|---|---|
| Data | دقیقاً چه داده/منبعی؟ |
| Purpose | کدام استفاده مشخص؟ |
| Necessity | برای خدمت لازم یا اختیاری؟ |
| Recipient | کدام Processor/Partner/Role؟ |
| Retention | تا چه Event/مدت؟ |
| Choice | opt in/out و اثر آن چیست؟ |
| Rights/Route | دسترسی، اصلاح، حذف، شکایت |
Change Notice
بهروزرسانی Terms یا Feature با جمله «ممکن است تغییر کند» تعهد اطلاعرسانی را حذف نمیکند. Notice باید Delta و Impact را نشان دهد، نه فقط لینک نسخه جدید.
| بخش | نمونه |
|---|---|
| What changed | Feature X از پلن A حذف میشود |
| Why | علت قابلبیان و بدون Spin |
| Who/Impact | حسابها، Workflow و هزینه |
| Effective date | تاریخ و Time zone |
| Choice | accept/migrate/export/cancel |
| Support | Route، SLA و مسئول |
Incident Notice؛ قبل از کاملشدن Root cause
صبر برای قطعیت کامل میتواند زیان مشتری را بیشتر کند. اولین Notice باید آنچه اکنون میدانید و نمیدانید را جدا کند؛ سپس در Cadence مشخص Update شود.
| بخش | محتوا |
|---|---|
| Observed | چه رخ داده و از چه زمانی |
| Affected/not affected | Scope فعلی و Confidence |
| Unknown | پرسشهای باز، بدون حدس |
| Customer action | کار فوری و Priority |
| Company action | Containment و Owner |
| Next update | زمان قطعی حتی بدون خبر جدید |
| Support/remedy | Route، SLA، Eligibility |
Trust Repair بعد از Failure
| مرحله | خروجی | Anti-pattern |
|---|---|---|
| Protect/contain | توقف زیان و راه امن | PR قبل از ایمنی |
| Acknowledge | واقعیت، Impact، مسئولیت | «اگر ناراحت شدید» |
| Explain | Known cause و Unknown | توجیه یا مقصر بیرونی |
| Remedy | refund/credit/restore/choice | کد تخفیف نامرتبط |
| System fix | control، owner، verification | وعده «تکرار نمیشود» |
| Follow-up | Evidence، closure، recurrence | سکوت پس از بحران |
عذرخواهی بدون اقدام عملکردی میتواند Integrity را ضعیفتر کند. Service recovery و جبران را با نوع زیان و ترجیح مشتری تطبیق دهید؛ Forgiveness یا دفاع از برند را مطالبه نکنید.
مرزهای افشا
| اطلاعات | پاسخ | جایگزین شفاف |
|---|---|---|
| داده شخصی فرد دیگر | عدم افشا/Redact | فرایند و نتیجه تجمیعی |
| جزئیات قابلسوءاستفاده امنیتی | Delay/limit audience | Risk، Action و timeline |
| ادعای تأییدنشده | برچسب Unknown/under review | روش بررسی و Update |
| اسرار تجاری نامرتبط | عدم افشا | معیار/Assurance مستقل |
| موضوع ایمنی کارکنان/مشتری | حداقل لازم و حفاظت | Owner و Escalation امن |
| تحقیق فعال | Scope محدود | وجود تحقیق و موعد Update |
«محرمانه است» نباید پاسخ نهایی باشد. توضیح دهید چه نوع اطلاعاتی چرا محدود است، چه چیزی اکنون قابلگفتن است و چه زمانی بازبینی میشود.
Single Source of Truth و Versioning
اگر Website، Sales deck، Contract و Support پاسخ متفاوت دهند، مشتری عملاً با چهار شرکت روبهروست. Truth source باید Source system، Owner، Version، Effective date و Dependent channels داشته باشد.
| کنترل | تعریف |
|---|---|
| Source of record | سیستم مرجع Price/Policy/Status |
| Publish pipeline | کدام Channelها خودکار/دستی |
| Dependency map | Page، Script، Proposal، Bot، FAQ |
| Version/effective | نسخه جاری و تاریخ اجرا |
| Rollback/correction | بازگشت، Notice و audit log |
Information Debt و Freshness SLA
Information debt فاصله انباشته میان واقعیت جاری و اطلاعات مشتری است: صفحه قدیمی، FAQ متناقض، Script فروش منسوخ یا Status سبز در زمان اختلال. Debt باید Backlog، Severity، Owner و موعد داشته باشد.
| Class | Freshness نمونه | Trigger |
|---|---|---|
| Price/availability | real-time/روزانه | config/stock change |
| Incident/status | دقیقه/ساعت | threshold/event |
| Terms/privacy | قبل effective date | approved policy |
| Product claims | هر release/quarter | evidence expiry |
| CSR/sustainability | دوره گزارش + event | method/scope change |
Comprehension Test؛ انتشار مساوی فهم نیست
- از مشتری هدف بخواهید Price/Restriction/Action را با زبان خود بازگو کند.
- Time-to-find را برای اطلاعات Material بسنجید.
- Benefit و Limitation را با وزن بصری مشابه تست کنید.
- نسخه Mobile، Screen reader و سرعت پایین را بررسی کنید.
- ترجمه و اصطلاح تومان/ریال را با کاربر واقعی تست کنید.
- اگر پاسخ اشتباه است، مشکل را «بیدقتی مشتری» ننامید؛ Message را اصلاح کنید.
Dashboard شفافیت و اعتماد
| لایه | شاخص | Guardrail |
|---|---|---|
| Disclosure | material claims with owner/evidence | تعداد صفحه KPI نیست |
| Clarity | comprehension/first-pass success | sample مشخص |
| Accuracy | claim defect/correction rate | کشف بیشتر ابتدا بد به نظر میرسد |
| Freshness | stale exposure minutes/customers | Severity-weighted |
| Action | resolution/refund/export success | Friction و زمان |
| Experience | trust item/complaint theme | Trust ≠ Loyalty |
| Behavior | repeat purchase/churn by cohort | Price/availability rivals |
| Guardrail | privacy/security harm | صفر افشا هدف نیست |
Feedback درباره شفافیت را Close کنید
اگر مشتری تناقض Price یا Claim را گزارش میکند، آن را فقط Ticket فردی نبندید. Case باید Source claim، همه مشتریان در معرض، Correction، Notice و Preventive control داشته باشد. Closed-loop VoC کمک میکند Signal تکرارشونده به تغییر سیستم برسد.
پیوند کارکنان و تجربه مشتری را ساده نکنید
Script شفاف زمانی پایدار است که کارکنان به Truth source، اختیار توقف Claim و کانال گزارش تناقض دسترسی داشته باشند. اما Satisfaction کارکنان خودبهخود Customer trust نمیسازد. مسیرهای عملیاتی و داده را طبق راهنمای پیوند EX و CX جدا بسنجید.
اخلاق، Speak-up و Claim challenge
کارمند باید بتواند ادعای فروش، تبلیغ یا گزارش را بدون Retaliation به چالش بکشد. Review مستقل، Conflict disclosure و ثبت Override لازم است. سازوکار گزارش امن و پاسخگویی در راهنمای رفتار اخلاقی سازمان آمده است.
شفافیت ادعاهای CSR و زنجیره تأمین
واژههایی مثل «سبز»، «اخلاقی» یا «حامی جامعه» به Scope، Method، Baseline، Boundary و Limit نیاز دارند. یک پروژه داوطلبانه کوچک نباید به Claim کل سازمان تبدیل شود. برای طراحی و Evidence برنامه به راهنمای CSR مراجعه کنید.
سناریوی ایران: فروشگاه آنلاین و قیمت نهایی
محصول با قیمت اولیه نمایش داده میشود، اما هزینه ارسال و نصب پس از ورود آدرس اضافه میشود. تیم فقط Checkout را اصلاح نمیکند: Claim Register تمام Bannerها و مقایسهها را پیدا میکند؛ «از X تومان» با شرط و تاریخ میآید؛ Total price پیش از تعهد دیده میشود؛ سفارشهای در معرض اطلاعات غلط برای Remedy بررسی میشوند.
سناریوی ایران: SaaS و قطعی سرویس
Status page سبز است، Support پاسخهای متفاوت میدهد و Root cause کامل نیست. Incident commander Scope فعلی، Unknown، Workaround و زمان Update بعدی را منتشر میکند. پس از Restore، Incident timeline، Credit eligibility، Control fix و Verification میآید. عبارت «مشکل رفع شد» بدون Impact و Remedy Closure نیست.
سناریوی ایران: تولیدکننده و تأخیر تحویل
Sales همچنان Lead time دهروزه میگوید، درحالیکه تأمین قطعه آن را به ۳۰ روز رسانده است. Trigger تغییر موجودی باید Quote، Website و Script را همزمان Update کند. مشتریان سفارشداده با Choice تحویل جدید، محصول جایگزین یا Refund مواجه میشوند؛ Gap بهعنوان Information debt با Owner ثبت میشود.
RACI
| کار | R | A | C | I |
|---|---|---|---|---|
| Materiality/contract | Product/Legal/CX | Business owner | Customer/Privacy | Channels |
| Claim evidence | Claim owner | Function leader | Data/QA/Legal | Sales/Support |
| Price/terms publish | Commerce Ops | Finance/Product | Legal/CX | Customers |
| Incident notice | Incident comms | Incident commander | Security/Legal/Support | Affected |
| Correction/remedy | CX/Finance/Ops | Business owner | Customer/QA | Governance |
| Transparency audit | QA/Internal audit | Executive owner | Privacy/Ethics | Teams |
برنامه ۹۰روزه
| بازه | خروجی | Gate |
|---|---|---|
| روز ۱–۱۵ | Journey/material disclosure inventory | owner/scope |
| روز ۱۶–۳۰ | Claim Register و truth sources | evidence/version |
| روز ۳۱–۴۵ | Price/terms/data templates | comprehension/privacy |
| روز ۴۶–۶۰ | Change/incident/correction playbook | trigger/SLA |
| روز ۶۱–۷۵ | Pilot یک Journey و دو Channel | accuracy/action |
| روز ۷۶–۹۰ | Information debt burn-down و scale memo | capacity/audit |
Anti-patternها
- شفافیت بیشتر همیشه اعتماد و فروش را بیشتر میکند.
- Privacy policy طولانی بهعنوان Consent.
- Disclaimer دور از Claim اصلی.
- قیمت پایه بدون Total cost و اعتبار.
- ویرایش بیصدای Claim یا Terms.
- Status سبز در زمان Failure شناختهشده.
- «در حال بررسی» بدون Unknown و Next update.
- عذرخواهی بدون Protection، Remedy و System fix.
- انتشار Root cause حدسی برای سرعت.
- افشای PII یا جزئیات امنیتی به نام شفافیت.
- اعلام CSR بدون Scope/Method/Limit.
- NPS یا خرید مجدد بهعنوان اثبات Trust.
چکلیست QA
- اطلاعات Material هر Moment تعریف شده است؟
- هر Claim، Evidence، Owner، Scope و Expiry دارد؟
- Benefit و Limitation نزدیک و هموزناند؟
- Price واحد، هزینه نهایی، اعتبار و Refund را نشان میدهد؟
- Data notice Purpose، Recipient، Retention و Choice دارد؟
- Change notice Delta، Impact، Date و Option دارد؟
- Incident notice Known، Unknown، Action و Next update دارد؟
- Privacy/Security/Safety boundary مرور شده است؟
- Truth source و Freshness SLA روشناند؟
- Comprehension و Correction با کاربر واقعی آزموده شدهاند؟
پرسشهای متداول
شفافیت در کسبوکار دقیقاً چیست؟
کیفیت اطلاعاتی است که مشتری برای تصمیم و اقدام دریافت میکند: Disclosure کافی، Clarity، Accuracy، Timing، Findability، Verifiability و Actionability. انتشار حجم زیاد سند، بهتنهایی Transparency نیست.
آیا باید همه اطلاعات شرکت را به مشتری گفت؟
خیر. اطلاعات Material برای تصمیم، هزینه، ایمنی، داده و حق جبران باید روشن باشد؛ داده شخصی، جزئیات امنیتی قابلسوءاستفاده، اسرار نامرتبط و ادعاهای تأییدنشده نیازمند Redaction، تأخیر یا محدودیتاند. دلیل و زمان بازبینی محدودیت را توضیح دهید.
شفافیت چگونه اعتماد مشتری را افزایش میدهد؟
میتواند فاصله انتظار و واقعیت را کم و ارزیابی Ability، Integrity و Benevolence را ممکن کند؛ اما اثر به صحت، وضوح، Context و عملکرد واقعی وابسته است. خبر بد شفاف ممکن است اعتماد را زیاد نکند، ولی تصمیم را کالیبره میکند.
در زمان خطا یا قطعی چه چیزی اعلام کنیم؟
Observed event، زمان، Scope فعلی، بخشهای متأثر/نامتأثر، Unknownها، اقدام مشتری، Containment شرکت، زمان Update بعدی و Route حمایت/جبران را اعلام کنید. Root cause حدسی منتشر نکنید.
شفافیت کسبوکار را چگونه بسنجیم؟
Coverage ادعاهای Material، comprehension، defect/correction، stale exposure، resolution friction و guardrailهای Privacy/Security را بسنجید. Trust، Satisfaction، خرید مجدد و Loyalty را سازههای جدا با فرضهای رقیب نگه دارید.
جمعبندی
شفافیت قابلاعتماد از صداقت فردی فراتر میرود؛ به Contract، Owner، Evidence، Version، Trigger و Correction نیاز دارد. مشتری باید پیش از تصمیم بداند چه چیزی میخرد، چه محدودیتی وجود دارد و اگر واقعیت تغییر کرد چه انتخابی دارد.
Claim Register و Freshness SLA از اطلاعات منسوخ پیشگیری میکنند؛ Incident Notice و Trust Repair آسیب را پنهان نمیکنند و به Remedy میرسانند. افشای کمتر یا بیشتر هدف نیست؛ اطلاعات درست، روشن، بهموقع و قابلاقدام هدف است.
